[BUGS] BUG #5965: PostgreSQL crashes during connection
The following bug has been logged online: Bug reference: 5965 Logged by: Daniel Migowski Email address: dmigow...@ikoffice.de PostgreSQL version: 8.3.9 Operating system: Windows 7 Description:PostgreSQL crashes during connection Details: Hi, My PostgreSQL server just crashed during an attempt to connect to it (multiple times at once, a connection pool just started up). These lines were found in the logfile afterwards: 2011-04-06 11:38:03 CEST [2860] LOG: server process (PID 19812) was terminated by exception 0xC12D 2011-04-06 11:38:03 CEST [2860] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. 2011-04-06 11:38:03 CEST [2860] LOG: terminating any other active server processes 2011-04-06 11:38:03 CEST [12208] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [12208] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [12208] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [23548] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [23548] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [23548] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [24024] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [24024] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [24024] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [120] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [120] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [120] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [10948] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [10948] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [10948] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [26172] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [26172] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [26172] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [12176] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [12176] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [12176] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [3420] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [3420] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [3420] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [11184] WARNING: terminating connection because of crash of another server process 2011-04-06 11:38:03 CEST [11184] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2011-04-06 11:38:03 CEST [11184] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2011-04-06 11:38:03 CEST [7664] WARNING: terminating connection because of crash of another server process 2011-04-
Re: [BUGS] BUG #5965: PostgreSQL crashes during connection
Excerpts from Daniel Migowski's message of mié abr 06 06:45:25 -0300 2011: > PostgreSQL version: 8.3.9 > Operating system: Windows 7 > My PostgreSQL server just crashed during an attempt to connect to it > (multiple times at once, a connection pool just started up). > > These lines were found in the logfile afterwards: > > 2011-04-06 11:38:03 CEST [2860] LOG: server process (PID 19812) was > terminated by exception 0xC12D Upgrade to 8.3.14 and let us know how it goes. > I get these crashes occasionally, and don't know if they have been fixed in > a later version. Sorry for not using the bleeding edge version :). No, that cannot be forgiven really. -- Álvaro Herrera -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5966: extract(epoch..) function error
The following bug has been logged online:
Bug reference: 5966
Logged by: Ricardo Solanilla
Email address: i...@abaco-tandil.com.ar
PostgreSQL version: 8.3.0 b.1400
Operating system: windows nt
Description:extract(epoch..) function error
Details:
-- try this
select (extract(epoch from (date('2011-03-20'))) - extract(epoch from
(date('2011-03-19' / 3600
-- it must be 24 (hours), only occurs in march 19,2011
-- in v. 8.0 work fine!!
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Failed assert ((data - start) == data_size) in heaptuple.c
Hi folks,
I am running a 9.0.3 Hot Standy + Streaming Replication slave which
occasionally segfaults (every 1-2 days). I rebuilt Postgres with
--enable-cassert and --enable-debug, switched on core dumping and
waited for some results.
The first crash since enabling debugging was a failed assert in heaptuple.c:
TRAP: FailedAssertion("!((data - start) == data_size)", File:
"heaptuple.c", Line: 255)
2011-04-07 04:20:20 EST LOG: server process (PID 32195) was
terminated by signal 6: Aborted
2011-04-07 04:20:20 EST LOG: terminating any other active server processes
For context, the only things running on this server are the slave
database, and a tomcat instance. The tomcat instance is the only
connection into this database, which continually runs through a series
of SELECTs (100ms sleep between each run).
The slave database is basically stock standard 9.0.3 config, apart
from the replication setup and shared_buffers increased to 2GB.
Here's the backtrace:
Core was generated by `postgres: backend surecast 127.0.0.1(37155)
SELECT'.
Program terminated with signal 6, Aborted.
#0 0x7f40a93aba75 in *__GI_raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0 0x7f40a93aba75 in *__GI_raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x7f40a93af5c0 in *__GI_abort () at abort.c:92
#2 0x006f861d in ExceptionalCondition (conditionName=,
errorType=, fileName=,
lineNumber=) at assert.c:57
#3 0x00459b07 in heap_form_minimal_tuple
(tupleDescriptor=0xf6bdd0, values=0x8,
isnull=0xf6c680 "") at heaptuple.c:1459
#4 0x00580d12 in ExecFetchSlotMinimalTuple (slot=0xf6bb90) at
execTuples.c:684
#5 0x00588d10 in ExecHashTableInsert (hashtable=0xf4c3b0, slot=0x7dc3,
hashvalue=6) at nodeHash.c:697
#6 0x00589bf6 in MultiExecHash (node=)
at nodeHash.c:123
#7 0x0058a9ab in ExecHashJoin (node=0xf24008) at nodeHashjoin.c:154
#8 0x005788a8 in ExecProcNode (node=0xf24008) at execProcnode.c:427
#9 0x0058fb21 in ExecNestLoop (node=0xf8eb98) at nodeNestloop.c:120
#10 0x005788c8 in ExecProcNode (node=0xf8eb98) at execProcnode.c:419
#11 0x0057756d in ExecutePlan (queryDesc=0xf8bc30,
direction=32195, count=0)
at execMain.c:1187
#12 standard_ExecutorRun (queryDesc=0xf8bc30, direction=32195,
count=0) at execMain.c:280
#13 0x00642e28 in PortalRunSelect (portal=0xf11f88,
forward=,
count=0, dest=0xe00120) at pquery.c:952
#14 0x006442e9 in PortalRun (portal=,
count=, isTopLevel=,
dest=, altdest=,
completionTag=) at pquery.c:796
#15 0x006419e3 in exec_execute_message (argc=,
argv=, username=) at
postgres.c:2003
#16 PostgresMain (argc=, argv=,
username=) at postgres.c:3988
#17 0x00606a07 in BackendRun () at postmaster.c:3555
#18 BackendStartup () at postmaster.c:3242
#19 ServerLoop () at postmaster.c:1431
#20 0x0060931d in PostmasterMain (argc=14918336, argv=0xdfb160)
at postmaster.c:1092
#21 0x005a9310 in main (argc=5, argv=0xdfb140) at main.c:188
Let me know if there is any additional information I can provide.
Cheers,
BJ
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Failed assert ((data - start) == data_size) in heaptuple.c
Brendan Jurd writes:
> TRAP: FailedAssertion("!((data - start) == data_size)", File:
> "heaptuple.c", Line: 255)
[ scratches head ... ] That implies that heap_fill_tuple came to a
different conclusion about a tuple's data size than the immediately
preceding heap_compute_data_size. Which I would sure want to believe
is impossible. Have you checked for flaky memory on this machine?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
