Re: terminated by signal 6 problem - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: terminated by signal 6 problem
Date
Msg-id 411A6F4A.8030206@Yahoo.com
Whole thread Raw
In response to terminated by signal 6 problem  (Joe Conway <mail@joeconway.com>)
Responses Re: terminated by signal 6 problem  (Joe Conway <mail@joeconway.com>)
Re: terminated by signal 6 problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Add Missing From?
Next
From: Gaetano Mendola
Date:
Subject: Re: will PITR in 8.0 be usable for "hot spare"/"log shipping" type