tudorbarascu | 21 May 09:41 2013
Picon

BUG #8172: entering the hostname in the address column in pg_hba.conf doesn't work as it should

The following bug has been logged on the website:

Bug reference:      8172
Logged by:          Barascu Tudor
Email address:      tudorbarascu <at> yahoo.com
PostgreSQL version: 9.2.4
Operating system:   Centos 6.4 kernel  2.6.32-358.6.2.el6.x86_64
Description:        

In pg_hba.conf I have the following setup:
host    all     all     laptop          md5

Although the hostname gets resolved by the system (LAN DNS server) I still
get the no pg_hba.conf entry error.
If I enter the hostname and ip in the hosts file all works well.
I get the following error: (it seems the host name gets resolved but after
the deny)

2013-05-21 10:26:12 EEST:192.168.1.6(51513):sde <at> gisdb:[1997]: FATAL:  28000:
no pg_hba.conf entry for host "192.168.1.6", user "sde", database "gisdb",
SSL off
2013-05-21 10:26:12 EEST:192.168.1.6(51513):sde <at> gisdb:[1997]: DETAIL: 
Client IP address resolved to "192.168.1.6", forward lookup not checked.
2013-05-21 10:26:12 EEST:192.168.1.6(51513):sde <at> gisdb:[1997]: LOCATION: 
ClientAuthentication, auth.c:479

Thank you,
Tudor

--

-- 
(Continue reading)

Trond.Endrestol | 20 May 09:32 2013

BUG #8171: Log messages lacking enough details

The following bug has been logged on the website:

Bug reference:      8171
Logged by:          Trond Endrestøl
Email address:      Trond.Endrestol <at> ximalas.info
PostgreSQL version: 9.2.4
Operating system:   FreeBSD/amd64 9.1-STABLE r250805
Description:        

The log message:

LOG:  could not bind IPv6 socket: Can't assign requested address

should be augmented to reveal the attempted address, thus making the lives
of us poor db admins a lot easier. Likewise for any similar IPv4 related log
messages.

In fact all kinds of log/warning/error messages should be to the point and
include all(!) relevant details and not just a vague description of what
happened.

The above log message was due to the file /etc/hosts containing the two
lines:

localhost fe80::1
localhost fe80:2::1

Changing these two lines to:

localhost-6ll fe80::1
(Continue reading)

chris.travers | 20 May 06:51 2013
Picon

BUG #8170: alter user does not accept timestamp output format in certain datestyles and timezones.

The following bug has been logged on the website:

Bug reference:      8170
Logged by:          Chris Travers
Email address:      chris.travers <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   Debian Linux
Description:        

I have a pl/pgsql function which calculates at imestamp and alters a user's
password to be valid for 24 hours pending a password change.  When the
datestyle and timezone are set to certain settings this throws an
exception.

Here is an approximation without plpgsql:

db=# show timezone;
   TimeZone   
--------------
 Asia/Jakarta
(1 row)

db=# show datestyle;
   DateStyle   
---------------
 Postgres, DMY
(1 row)

db=# select now();
                 now                 
(Continue reading)

email4rajeshk | 18 May 14:01 2013
Picon

BUG #8169: change in bytea value in postgresql 8.3 and 9.2.4

The following bug has been logged on the website:

Bug reference:      8169
Logged by:          RAJESH KRISHNAN K
Email address:      email4rajeshk <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   RHEL 6
Description:        

There is a huge change in bytea value in postgresql 8.3 and 9.2.4

Can we convert 9.2.4 bytea value to 8.3

PLease Help

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

vladimir.jovanovic | 17 May 12:31 2013

BUG #8168: duplicated function signature

The following bug has been logged on the website:

Bug reference:      8168
Logged by:          Vladimir Jovanović
Email address:      vladimir.jovanovic <at> aparteko.com
PostgreSQL version: 8.4.11
Operating system:   PostgreSQL 8.4.11 on x86_64-redhat-linux-gnu, com
Description:        

Hi,

I noticed that I have two functions with the same signature.

sp_get_league_prediction(IN _id bigint, IN _rank integer, IN
_log_in_expectence double precision, IN _feathers_gained integer, IN
_tokens_all integer, IN _tokens_active integer, IN _score integer)

sp_get_league_prediction(_id bigint, _rank integer, _log_in_expectence
double precision, _feathers_gained integer, _tokens_all integer,
_tokens_active integer, _score integer)

Actually, I created first one with intention, but the second function
appeared when I executed the following code when I wanted to replace the
function:

CREATE OR REPLACE FUNCTION sp_get_league_prediction(IN _id bigint, IN _rank
integer, IN _log_in_expectence double precision, IN _feathers_gained
integer, IN _tokens_all integer, IN _tokens_active integer, IN _score
integer)
  RETURNS SETOF record AS
(Continue reading)

hubert depesz lubaczewski | 16 May 22:34 2013

pg_ctl -D "/absolute/path" -m fast restart - doesn't work in some cases

hi,
I have 9.3beta1, and strange problem.

Have running slave pg in directory /home/test/test/slave:

=$ pwd
/home/test/test/slave

=$ cat postmaster.pid 
16961
/home/test/test/slave
1368736261
5433
/tmp
*
  5433001   7241781

=$ ps uxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
test     16961  0.2  0.1 173528 12912 pts/7    S    22:31   0:00 /home/pgdba/work/bin/postgres -D test/slave
test     16970  0.0  0.0  27020   812 ?        Ss   22:31   0:00  \_ postgres: logger process                   
test     16971  4.0  0.0 173640  5724 ?        Ss   22:31   0:00  \_ postgres: startup process   recovering 00000001000000000000001B
test     17008  0.0  0.0 173528   972 ?        Ss   22:31   0:00  \_ postgres: checkpointer process             
test     17009  0.0  0.0 173528  1244 ?        Ss   22:31   0:00  \_ postgres: writer process                   
test     17028  0.0  0.0  29116   888 ?        Ss   22:31   0:00  \_ postgres: stats collector process          
test     17029  2.8  0.0 190652  4232 ?        Ds   22:31   0:00  \_ postgres: wal receiver process   streaming 0/1B7917E0
...

All looks fine. But when I'll try to restart it:
(Continue reading)

Josh Kupershmidt | 16 May 21:33 2013
Picon

easy crash on HEAD

I am pretty sure this is an easily-reproducible crash on git head
(well, as of a2a480af889b5), helpfully confirmed on IRC by wulczer and
deko. I reproduced the crash myself on OS X and 64-bit Debian.

---
create table foo (a int);
CREATE RULE notify_foo_updates AS ON UPDATE TO foo DO NOTIFY foo;
\d foo
---

Backtrace looks like this:
(gdb) bt
#0  0x00007fff837ce954 in recvfrom ()
#1  0x0000000100188fe3 in secure_read (port=0x100802280,
ptr=0x10055d340, len=8192) at be-secure.c:304
#2  0x0000000100191bdc in pq_recvbuf () at pqcomm.c:854
#3  0x0000000100192053 in pq_getbyte () at pqcomm.c:895
#4  0x0000000100257fec in SocketBackend [inlined] () at
/media/src/OSS/postgresql/src/backend/tcop/postgres.c:344
#5  0x0000000100257fec in ReadCommand (inBuf=0x7fff5fbfe0d0) at postgres.c:492
#6  0x0000000100258746 in PostgresMain (argc=1, argv=0x10101a010,
dbname=0x101019e78 "adsync", username=<value temporarily unavailable,
due to optimizations>) at postgres.c:3946
#7  0x0000000100204a95 in BackendRun [inlined] () at
/media/src/OSS/postgresql/src/backend/postmaster/postmaster.c:3985
#8  0x0000000100204a95 in ServerLoop () at postmaster.c:3674
#9  0x00000001002083d4 in PostmasterMain (argc=3, argv=0x100800700) at
postmaster.c:1244
#10 0x0000000100194089 in main (argc=3, argv=0x100800700) at main.c:196

(Continue reading)

weiwei | 16 May 11:14 2013
Picon

Postgresql 9.12 support cluster mode

Dear hello:
Postgresql 9.12 support cluster mode? Equivalent of main spare automatic switching
 

 

电话:010-87120766-5738

手机:13371663316

邮件:weiwei <at> ti-net.com.cn

 

 
nelson | 16 May 03:17 2013

BUG #8167: false EINVAL -22 for opening a file

The following bug has been logged on the website:

Bug reference:      8167
Logged by:          Nelson Minar
Email address:      nelson <at> monkey.org
PostgreSQL version: 9.2.4
Operating system:   MacOS 10.8.3
Description:        

This report and supporting files are available at
https://gist.github.com/NelsonMinar/5588719

I have a PostGIS insert/select operation that creates rows in a table.
Mostly these operations succeed, but every once in awhile one fails
with an error like
  ERROR:  could not open file "base/16384/24738_fsm": Invalid argument
Googling for this error shows it's occurred occasionally for other Mac
users, but I haven't seen any consistent explanation or solution.

I traced this down with the help of RhodiumToad and anders on IRC
#postgresql. Their guess was that the problem is that Postgres is
calling open() followed by free() before checking errno for open().
The call to free() subsequently calls madvise(), which throws EINVAL,
clobbering the ENOENT that open() set. When Postgres finally checks if
the open() worked it sees the EINVAL from the madvise() instead and
mistakenly reports a problem opening the file. It's unclear whether
the EINVAL from madvise() is a real error or just part of the normal
operation of free() on MacOS.

RhodiumToad asked me to report "pg in PathNameOpenFile / mdopen is
assuming that errno is preserved over calls to free() which is not
required by the spec" and "madvise is using MADV_FREE_REUSABLE".

I've attached dtruss output to this gist for both a successful query
and a failed query. Here's the essential part of the trace of a
failure:

open("base/16384/24738_fsm\0", 0x2, 0x180)       = -1 Err#2
madvise(0x7FB983489000, 0x1000, 0x7)         = -1 Err#22
sigprocmask(0x3, 0x7FFF580A0420, 0x0)        = 0x0 0
sigreturn(0x0, 0x80000000, 0x0)      = 0 0
write(0x2, "ERROR:  could not open file \"base/16384/24738_fsm\": Invalid
argument\nSTATEMENT:  insert into merged_rivers(gnis_id, name, strahler,
huc8, geometry)\n\t                select\n\t                   
MAX(gnis_id) as gnis_id,\n\t                    MAX(name) as name", 0x204)  
    = 516 0
sendto(0xC, 0x7FB983841030, 0x65)        = 101 0

Environment:

MacOS 10.8.3 Postgres 9.2.4 installed via Homebrew

I'm not positive if Postgres was built with gcc or clang. Here's the
compiler versions:

i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.11.00)

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target:
x86_64-apple-darwin12.3.0 Thread model: posix

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Sean Chittenden | 15 May 22:54 2013

WAL partition ran out of space, pg_subtrans & pg_clog partially written...

This is an FYI re: a bug I ran across.

Background: RHEL 6 & ext4. PGDATA, a table space, and WAL logs are all on their own partitions.

The WAL partition filled up (wal_keep_segments was changed, but Pg hadn't been restarted), and a write
happened, and it appears to have resulted in an index page being corrupt. REINDEX'ing the table didn't
work with the following error:

> WARNING: concurrent delete in progress within table "tblA"

> WARNING: concurrent delete in progress within table "tblA"
> ERROR: could not access status of transaction 86081816
> DETAIL: Could not read from file "pg_subtrans/0521" at offset 131072: Success.

pg_subtrans/0521 was a 90112 byte file and pg_clog/0052 was 24576 bytes in size.

I haven't dug in to the code, but I did see the commit message for
pgsql/src/backend/access/transam/slru.c 1.23.4.2, which I'm guessing is related. My WAG is that
there's an assumption someplace that pg_subtrans and pg_clog are on the same partition as pg_xlog, or
that creation of files in pg_subtrans and pg_clog will either absolutely succeed or absolutely fail. It
could also be that Linux reported back a successful write(2), but it didn't actually have the space
available (ext4).

Anyway, after extending pg_subtrans/0521 w/ zeros to its proper 256KB size, I was able to REINDEX the
table, but there was a stream of WARNINGs about "concurrent inserts and deletes" that I didn't dig in to.
Upon learning the WAL files were removed as a temporary solution to the space problem, I opted to dump,
re-initdb, and load the data, which worked without any errors or warnings being reported.

I've saved the data if there are pointed questions about their contents.

-sc

--
Sean Chittenden
sean <at> chittenden.org

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

tcook | 15 May 19:27 2013

BUG #8163: simultaneous nearly identical update queries execute extremely slowly

The following bug has been logged on the website:

Bug reference:      8163
Logged by:          Todd Cook
Email address:      tcook <at> blackducksoftware.com
PostgreSQL version: 8.4.16
Operating system:   Fedora 14
Description:        

When nearly identical update queries arrive simultaneously, the first one to
execute runs normally, but subsequent executions run _extremely_ slowly. 
We've seen this behaviour in production, and the contrived test case below
reproduces the issue.

test=> select version() ;
                                                      version               

--------------------------------------------------------------------------------------------------------------------
 PostgreSQL 8.4.16 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.4.4 20100726 (Red Hat 4.4.4-13), 64-bit

To set up:

create table prof as select i as id, i::text col1, (i*2)::text col2 ,
(i*3)::text col3, i*2 col4, md5((i % 5999)::text) as hash, (i % 6000)::text
as hint, (i*4)::text col6, i*5 col7, i*6 col8 from
generate_series(1,36000000) i ;
create table tree as select 'fixed16charstrng'::text as changeme, md5((i %
200000)::text) as hash from generate_series(1,400000) i ;
create index tree_hash_idx on tree(hash) ;

The problematic query run in isolation:

explain analyze update tree set changeme = 'changed' where hash in (select
hash from prof where hint = '2500') ;
                                                          QUERY PLAN        

------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=1000098.75..1000104.44 rows=11583 width=39) (actual
time=6765.316..6871.167 rows=11998 loops=1)
   ->  HashAggregate  (cost=1000098.75..1000098.76 rows=1 width=33) (actual
time=6765.264..6768.259 rows=5999 loops=1)
         ->  Seq Scan on prof  (cost=0.00..1000084.15 rows=5840 width=33)
(actual time=1.351..6755.691 rows=6000 loops=1)
               Filter: (hint = '2500'::text)
   ->  Index Scan using tree_hash_idx on tree  (cost=0.00..5.65 rows=2
width=39) (actual time=0.014..0.016 rows=2 loops=5999)
         Index Cond: (tree.hash = prof.hash)
 Total runtime: 7132.700 ms
(7 rows)

To exercise the problem (assuming a database named "test"):
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2500')" test &
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2501')" test &
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2502')" test &
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2503')" test &
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2504')" test &
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2505')" test &
psql -c "update tree set changeme = 'changed' where hash in (select hash
from prof where hint = '2506')" test &

One of the update begins executing immediately, while the others block
waiting on the first (which is expected). The first update finished in under
10 seconds, and another one started executing; however, this second one has
now been executing for 2 hours.

strace output from that backend is almost exclusively reads, with only a few
calls to lseek.  Attaching with gdb and interrupting a few times mostly gave
this backtrace:

#0  0x0000003b812d3490 in __read_nocancel () from /lib64/libc.so.6
#1  0x00000000005cd0cd in FileRead ()
#2  0x00000000005dc55d in mdread ()
#3  0x00000000005ca315 in ReadBuffer_common ()
#4  0x00000000005cac7f in ReadBufferExtended ()
#5  0x0000000000460c8b in heapgetpage ()
#6  0x000000000046110a in heapgettup_pagemode ()
#7  0x0000000000461b56 in heap_getnext ()
#8  0x000000000054ef18 in SeqNext ()
#9  0x00000000005429ba in ExecScan ()
#10 0x000000000053b8a8 in ExecProcNode ()
#11 0x0000000000547ac8 in ExecAgg ()
#12 0x000000000053b7b8 in ExecProcNode ()
#13 0x000000000054e031 in ExecNestLoop ()
#14 0x000000000053b818 in ExecProcNode ()
#15 0x000000000053827e in EvalPlanQualNext ()
#16 0x000000000053867b in EvalPlanQual ()
#17 0x0000000000539afd in standard_ExecutorRun ()
#18 0x00007f796347881b in pgss_ExecutorRun (queryDesc=0x1af53b0,
direction=ForwardScanDirection, count=0) at pg_stat_statements.c:516
#19 0x00000000005e3ad1 in ProcessQuery ()
#20 0x00000000005e3cd4 in PortalRunMulti ()
#21 0x00000000005e4452 in PortalRun ()
#22 0x00000000005dfac9 in exec_simple_query ()
#23 0x00000000005e10f3 in PostgresMain ()
#24 0x00000000005b4e73 in ServerLoop ()
#25 0x00000000005b729e in PostmasterMain ()
#26 0x0000000000562578 in main ()

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Gmane