Re: terminated by signal 6 problem

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: terminated by signal 6 problem
Дата
Msg-id 411A6F4A.8030206@Yahoo.com
обсуждение исходный текст
Ответ на terminated by signal 6 problem  (Joe Conway <mail@joeconway.com>)
Ответы Re: terminated by signal 6 problem  (Joe Conway <mail@joeconway.com>)
Re: terminated by signal 6 problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Add Missing From?
Следующее
От: Gaetano Mendola
Дата:
Сообщение: Re: will PITR in 8.0 be usable for "hot spare"/"log shipping" type