Bug #488: Apache daemon dying on segfault from postgres

Started by PostgreSQL Bugs Listover 24 years ago3 messagesbugs
Jump to latest
#1PostgreSQL Bugs List
pgsql-bugs@postgresql.org

Darrell Parlee (darrell@parlee.net) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
Apache daemon dying on segfault from postgres

Long Description
I have stable code that runs without change from one iteration to the next. Get sporadic failures which indicate either a wild pointer problem or use of an uninitialized variable. Problem can't be consistently reproduced with a specific test case (well, at least I have not found it yet). But I did capture the following detail:

---------------------------------------
pgsql.c(167) : Block 0x0853D400 status:
Beginning: Overrun (magic=0x5A5A5A5A, expected=0x7312F8DC)
[Fri Oct 19 16:19:45 2001] [notice] child pid 8062 exit signal Segmentation fault (11)
[Fri Oct 19 16:20:03 2001] Script: '/home/httpd/ContractServer/pace/createtables.shtml'
---------------------------------------
pgsql.c(167) : Block 0x085363E0 status:
Beginning: Overrun (magic=0x00000000, expected=0x7312F8DC)
End: Unknown
---------------------------------------

File system content allows for growth, and no hardware errors are recorded by the logging daemons. This problem first began (as best I can recall) after adopting the 7.0 release. It has been present in every upgrade since then (.1/.2/.3).

Sample Code

No file was uploaded with this report

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: PostgreSQL Bugs List (#1)
Re: Bug #488: Apache daemon dying on segfault from postgres

pgsql-bugs@postgresql.org writes:

Apache daemon dying on segfault from postgres

And why exactly are you complaining to us, rather than the Apache folk?

regards, tom lane

In reply to: PostgreSQL Bugs List (#1)
SPI_modifytuple - why i cant use it in trigers fired after

fragment from PostgreSQL 7.1 Documentation:
"Trigger functions return HeapTuple to the calling Executor. This is
ignored for triggers fired after an INSERT, DELETE or UPDATE operation but
it allows BEFORE triggers to: ......"

can somebody tell my why ? is it bug or what ?
sometimes i have to use it AFTER insert, update or delete. what can i do
in this situation.

thank you in advance

--
Marek Bartnikowski <mailto:marek@virt.pl>
PostgreSQL DBA
C, PHP Prog.