Re: [HACKERS] terminated by signal 6 problem

[Jan Wieck]

I have seen similar when running under heavy load with high frequent 
insert+delete+vacuum. What happens is that adding another item to an 
index page in the btree access method fails. It seems to me that the 
decision to add an item to a page and the real work of actually adding 
it are not atomic, so that under certain race conditions two backends 
make the same decision while one would have to split the page.

Restarting the whole postmaster looks like overreacting also, but it 
apparently fixes the problem since the index is just fine and retrying 
the insert afterwards works.

Jan
On 8/10/2004 6:50 PM, Joe Conway wrote:
I was sent a log file for a production system that has received several 
ABORT signals while under heavy load. Here's a snippet from the logs:

-----------
LOG:  recycled transaction log file "0000000A0000004B"
LOG:  recycled transaction log file "0000000A0000004D"
LOG:  recycled transaction log file "0000000A0000004E"
LOG:  recycled transaction log file "0000000A0000004F"
WARNING:  specified item offset is too large
CONTEXT:  COPY cymi_transaction_data, line 174: "3448545602 62365 39 4 0.00"
PANIC:  failed to add item to the page for "pk_transaction_data"
CONTEXT:  COPY cymi_transaction_data, line 174: "3448545602 62365 39 4 0.00"
STATEMENT:  COPY cymi_transaction_data FROM STDIN;
LOG:  server process (PID 11667) was terminated by signal 6
LOG:  terminating any other active server processe
-----------
The server information as I was given it:
Sun server V250, 1 GHz Processor, 1 GB RAM, 4 x 72GB
I'm requesting more data -- not yet clear whether I can get a core dump 
or even if postgres is compiled with debug symbols on that machine.

The "WARNING:  specified item offset is too large" seems to happen each 
time there is an ABORT, leading me to think it might be bad RAM.

Any thoughts or specific data requests? I can send the full log off-list 
if needed.

Thanks,
Joe
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
               http://www.postgresql.org/docs/faqs/FAQ.html

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]