Re: terminated by signal 6 problem

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: terminated by signal 6 problem
Date: 2004-08-11 19:11:06
Message-ID: 411A6F4A.8030206@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2004-08-11 20:26:54 Re: will PITR in 8.0 be usable for "hot spare"/"log shipping" type
Previous Message Stephan Szabo 2004-08-11 18:37:06 Re: Add Missing From?