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

ranjita.nayak | 14 May 17:48 2013
Picon

BUG #8161: Several instances of Postgres service

The following bug has been logged on the website:

Bug reference:      8161
Logged by:          Ranjita
Email address:      ranjita.nayak <at> in.abb.com
PostgreSQL version: 9.2.4
Operating system:   Windows7
Description:        

Why multiple instances of postgres is running in task manager (around 10nos)
if we open the PgAdminIII ? 

--

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

majestio | 14 May 22:01 2013
Picon

BUG #8162: Operation would bloсk (0x00002733/10035)

The following bug has been logged on the website:

Bug reference:      8162
Logged by:          Majestio
Email address:      majestio <at> ya.ru
PostgreSQL version: 9.2.4
Operating system:   cross-compiling MinGW32 / WinXP x64
Description:        

Sorry for my English, I use a translator.

I built PostgreSQL using 
MinGW (x32-4.8.0-release-posix-sjlj-rev2.7z)
MSYS (msys +7 za + wget + svn + git + mercurial + cvs-rev12.7z)

The sequence building:

$ cd /prj/pgsql-x32
$ ./configure --with-openssl --without-zlib --prefix=/prj/pgsql/x32
--with-includes=/prj/openssl/x32/include
--with-libraries=/prj/openssl/x32/lib
$ make && make install

Building without any error. 

However, all the programs meet always the same error: 

    could not connect to server: Operation would block (0x00002733/10035)
             Is the server running on host "localhost" (127.0.0.1) and
accepting
             TCP/IP connections on port 5432?

The server is operational and is available if you use binaries obtained from
http://www.postgresql.org/download/windows/

WBR, Majestio

--

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

csibe1985.12 | 14 May 13:38 2013
Picon

BUG #8159: PostgreSQlk is not working

The following bug has been logged on the website:

Bug reference:      8159
Logged by:          Janos
Email address:      csibe1985.12 <at> freemail.hu
PostgreSQL version: 9.2.4
Operating system:   Vista
Description:        

Problem runninng post-install step.Installation may not complete correctly.
The database cluster initialisation failed.

--

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

bnicholson | 14 May 15:48 2013
Picon

BUG #8160: 9.3 Beta 1 Initdb doesn't work

The following bug has been logged on the website:

Bug reference:      8160
Logged by:          Brad Nicholson
Email address:      bnicholson <at> hp.com
PostgreSQL version: Unsupported/Unknown
Operating system:   CentOS release 6.2 (Final)
Description:        

Hi,

I've installed the 9.3 beta 1 packages (via pgdg repo and yum) and when I
try to do an initdb it fails. /var/lib/pgsql/9.3/data has nothing in it when
I attempt the initdb :

#service postgresql-9.3 initdb
Initializing database:[FAILED]

# cat /var/lib/pgsql/9.3/pgstartup.log
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.

fixing permissions on existing directory /var/lib/pgsql/9.3/data ... ok
creating directory /var/lib/pgsql/9.3/data/pg_xlog ... ok
initdb: could not create symbolic link "/var/lib/pgsql/9.3/data/pg_xlog":
File exists
initdb: removing contents of data directory "/var/lib/pgsql/9.3/data"
initdb: removing transaction log directory
"/var/lib/pgsql/9.3/data/pg_xlog"
could not open directory "/var/lib/pgsql/9.3/data/pg_xlog": No such file or
directory
initdb: failed to remove transaction log directory

Brad.

btw - on the bug reporting form, the popup version does not have 9.3 Beta as
an option for version

--

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

leif | 14 May 10:19 2013
Picon

BUG #8157: pg_dump and pg_dumpall fail when extension postgis_tiger_geocoder is installed

The following bug has been logged on the website:

Bug reference:      8157
Logged by:          Leif Gunnar Erlandsen
Email address:      leif <at> lako.no
PostgreSQL version: Unsupported/Unknown
Operating system:   Linux Fedora 18
Description:        

-bash-4.2$ psql
psql (9.3beta1)
Type "help" for help.

postgres=# select extname,extowner,extnamespace,extrelocatable,extversion
from pg_extension ;
        extname         | extowner | extnamespace | extrelocatable |
extversion 
------------------------+----------+--------------+----------------+------------
 plpgsql                |       10 |           11 | f              | 1.0
 postgis                |       10 |         2200 | t              |
2.1.0beta2
 postgis_topology       |       10 |        17668 | f              |
2.1.0beta2
 fuzzystrmatch          |       10 |         2200 | t              | 1.0
 postgis_tiger_geocoder |       10 |        17831 | f              |
2.1.0beta2
(5 rows)

postgres=# \q
-bash-4.2$ pg_dump
pg_dump     pg_dumpall  
-bash-4.2$ pg_dumpall > /dev/null
pg_dump: [archiver (db)] query failed: ERROR:  syntax error at or near "="
LINE 1: ...rd, token, is_custom FROM tiger.pagc_gaz is_custom=true) TO ...
                                                             ^
pg_dump: [archiver (db)] query was: COPY (SELECT id, seq, word, stdword,
token, is_custom FROM tiger.pagc_gaz is_custom=true) TO stdout;
pg_dumpall: pg_dump failed on database "postgres", exiting
-bash-4.2$ which pg_dumpall
/usr/pgsql-9.3/bin/pg_dumpall

--

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

lr | 14 May 06:31 2013
Picon

BUG #8156: PostGIS crash with immutable functions when immutable function throws an error

The following bug has been logged on the website:

Bug reference:      8156
Logged by:          Regina
Email address:      lr <at> pcorp.us
PostgreSQL version: 9.2.4
Operating system:   Windows 7 64-bit compiled with visual c++ - EDB 64
Description:        

Nothing to do yet unless its obvious to you folks what is wrong here.

I haven't determined if its an issue in how we are compiling PostGIS for
windows or something fundametally wrong in the 9.2 branch on how it handles
windows 64-bit.

Details in this ticket:

http://trac.osgeo.org/postgis/ticket/2185

The issue only seems to exhibit itself in PostgreSQL 9.2.2-9.2.4 (as I
recall 9.2.1 doesn't have this issue).

and it also only happens on windows 7-64bit and windows 2008 64-bit.  As far
as I can tell windows 2003 64-bit with same build doesn't have the issue and
as I recall I can't replicate this issue testing under mingw64 either which
we use to compile.

We've only seen it with SQL functions that wrap a PostGIS c function and
that are marked IMMUTABLE STRICT and happens when fed invalid inputs that
would raise an error in the C function.  If we take out the IMMUTABLE part
it works fine.

e.g.
This function will crash when  used with invalid inputs. such as
ST_AsText('POINT(1 3 hi)')

CREATE OR REPLACE FUNCTION st_astext(text)
  RETURNS text AS
' SELECT ST_AsText($1::geometry);  '
  LANGUAGE sql IMMUTABLE STRICT
  COST 100;

This variant the function (note no immutable)

CREATE OR REPLACE FUNCTION st_astextNotImmut(text)
  RETURNS text AS
' SELECT ST_AsText($1::geometry);  '
  LANGUAGE sql STRICT
  COST 100;

Makes it not crash.

The 9.3beta1 doesn't have this issue.  Nor does the latest 9.1 I have
tested.

--

-- 
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