Thread: aaagh... postgres is segfaulting?
I'm trying a fresh install of postgres on a redhat machine (gcc 2.96) compiled
from source.
I am getting messages along these lines in the logfile, and php is telling me
that the backend abruptly ended the connection.
How can i go about fixing this?
Josh.
LOG: database system was shut down at 2003-04-09 06:20:55 EDT
LOG: checkpoint record is at 0/1816C2C
LOG: redo record is at 0/1816C2C; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 5882; next oid: 164471
LOG: database system is ready
LOG: server process (pid 29227) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and
semaphores
LOG: database system was interrupted at 2003-04-09 06:22:07 EDT
LOG: checkpoint record is at 0/1816C2C
LOG: redo record is at 0/1816C2C; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 5882; next oid: 164471
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 0/1816C6C
LOG: ReadRecord: record with zero length at 0/181F160
LOG: redo done at 0/181F13C
LOG: database system is ready
LOG: server process (pid 18767) was terminated by signal 11
LOG: terminating any other active server processes
WARNING: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
WARNING: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
LOG: all server processes terminated; reinitializing shared memory and
semaphores
LOG: database system was interrupted at 2003-04-09 06:27:20 EDT
LOG: checkpoint record is at 0/184954C
LOG: redo record is at 0/184954C; undo record is at 0/0; shutdown FALSE
LOG: next transaction id: 6997; next oid: 172663
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 0/184958C
LOG: ReadRecord: record with zero length at 0/186DF6C
LOG: redo done at 0/186DF48
LOG: database system is ready
I needed to apply this... for some reason when I do timetamp related queries without executing that a segfault occurs. UPDATE pg_proc SET prorettype = 1114 WHERE prosrc = 'timestamptz_izone'; On April 9, 2003 06:39 am, Joshua Moore-Oliva wrote: > I'm trying a fresh install of postgres on a redhat machine (gcc 2.96) > compiled from source. > > I am getting messages along these lines in the logfile, and php is telling > me that the backend abruptly ended the connection. > > How can i go about fixing this? > > Josh. > LOG: database system was shut down at 2003-04-09 06:20:55 EDT > LOG: checkpoint record is at 0/1816C2C > LOG: redo record is at 0/1816C2C; undo record is at 0/0; shutdown TRUE > LOG: next transaction id: 5882; next oid: 164471 > LOG: database system is ready > LOG: server process (pid 29227) was terminated by signal 11 > LOG: terminating any other active server processes > LOG: all server processes terminated; reinitializing shared memory and > semaphores > LOG: database system was interrupted at 2003-04-09 06:22:07 EDT > LOG: checkpoint record is at 0/1816C2C > LOG: redo record is at 0/1816C2C; undo record is at 0/0; shutdown TRUE > LOG: next transaction id: 5882; next oid: 164471 > LOG: database system was not properly shut down; automatic recovery in > progress > LOG: redo starts at 0/1816C6C > LOG: ReadRecord: record with zero length at 0/181F160 > LOG: redo done at 0/181F13C > LOG: database system is ready > LOG: server process (pid 18767) was terminated by signal 11 > LOG: terminating any other active server processes > WARNING: Message from PostgreSQL backend: > The Postmaster has informed me that some other backend > died abnormally and possibly corrupted shared memory. > I have rolled back the current transaction and am > going to terminate your database system connection and exit. > Please reconnect to the database system and repeat your query. > WARNING: Message from PostgreSQL backend: > The Postmaster has informed me that some other backend > died abnormally and possibly corrupted shared memory. > I have rolled back the current transaction and am > going to terminate your database system connection and exit. > Please reconnect to the database system and repeat your query. > LOG: all server processes terminated; reinitializing shared memory and > semaphores > LOG: database system was interrupted at 2003-04-09 06:27:20 EDT > LOG: checkpoint record is at 0/184954C > LOG: redo record is at 0/184954C; undo record is at 0/0; shutdown FALSE > LOG: next transaction id: 6997; next oid: 172663 > LOG: database system was not properly shut down; automatic recovery in > progress > LOG: redo starts at 0/184958C > LOG: ReadRecord: record with zero length at 0/186DF6C > LOG: redo done at 0/186DF48 > LOG: database system is ready > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Wednesday 09 Apr 2003 12:25 pm, Joshua Moore-Oliva wrote: > I needed to apply this... for some reason when I do timetamp related > queries without executing that a segfault occurs. > > UPDATE pg_proc SET prorettype = 1114 WHERE prosrc = 'timestamptz_izone'; Hmm - mine reads 1186 (interval). Two questions: 1. Did you notice what value it had before? 2. Have you made the same change in template0/1 (and what values did they have)? Actually, a third question: how did you ever figure that out? -- Richard Huxton
On April 9, 2003 09:35 am, Richard Huxton wrote: > On Wednesday 09 Apr 2003 12:25 pm, Joshua Moore-Oliva wrote: > > I needed to apply this... for some reason when I do timetamp related > > queries without executing that a segfault occurs. > > > > UPDATE pg_proc SET prorettype = 1114 WHERE prosrc = 'timestamptz_izone'; > > Hmm - mine reads 1186 (interval). Two questions: > > 1. Did you notice what value it had before? Yea it had an interval before. > 2. Have you made the same change in template0/1 (and what values did they > have)? no I didn't touch template 0 or 1, but it just dawned on me that doing so may save a step for me having to run that command with every database I install. > > Actually, a third question: how did you ever figure that out? A whle ago I had this problem.. SELECT now() AT TIME ZONE interval '-5 hours' returns type interval not timestamp with//out time zone. A prety knowledgable guy Tom Lane suggested the above fix. When I was getting a segfault on a query similar to that it dawned on me that i may need to run that command again since I had moved the database to a new server, and presto it worked :) Josh.
Richard Huxton <dev@archonet.com> writes:
> Actually, a third question: how did you ever figure that out?
He probably looked in the archives and found the discussion associated
with this pg_proc.h change:
Revision 1.275.2.1, Fri Mar 14 04:44:05 2003 UTC (3 weeks, 5 days ago) by tgl
Branch: REL7_3_STABLE
Changes since 1.275: +8 -8 lines
Diff to previous 1.275 next main 1.276
Repair incorrect prorettype entry for timestamptz_izone. Can't force
initdb in the 7.3 branch, but we can at least make it right for people
who install 7.3.3 from scratch.
regards, tom lane
Actually it was due to your personal suggestion that I did it.. and thanks again for the help you gave me a month ago :) Josh. On April 9, 2003 11:36 am, Tom Lane wrote: > Richard Huxton <dev@archonet.com> writes: > > Actually, a third question: how did you ever figure that out? > > He probably looked in the archives and found the discussion associated > with this pg_proc.h change: > > Revision 1.275.2.1, Fri Mar 14 04:44:05 2003 UTC (3 weeks, 5 days ago) by > tgl Branch: REL7_3_STABLE > Changes since 1.275: +8 -8 lines > Diff to previous 1.275 next main 1.276 > > Repair incorrect prorettype entry for timestamptz_izone. Can't force > initdb in the 7.3 branch, but we can at least make it right for people > who install 7.3.3 from scratch. > > regards, tom lane