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
