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

From Joe Conway
Subject Re: terminated by signal 6 problem
Date
Msg-id 411A8786.2090402@joeconway.com
Whole thread Raw
In response to Re: terminated by signal 6 problem  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Jan Wieck wrote:
> I have seen similar when running under heavy load with high frequent 
> insert+delete+vacuum. What happens is that adding another item to an 

This fits the profile of this application perfectly.

> 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.

Hmmm, sounds like a somewhat serious issue. Any thoughts on a fix, or 
even a reliable workaround?

> 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.

But it is disruptive to an application that collects data 24 x 365 at 
this kind of load. I've been discussing with the developers ways to 
eliminate the delete and most of the vacuum load (in favor of "work" 
tables and TRUNCATE), so maybe this issue will force that change.

Thanks,

Joe


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: will PITR in 8.0 be usable for "hot spare"/"log shipping" type of replication
Next
From: Tom Lane
Date:
Subject: Re: terminated by signal 6 problem