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
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
Jan Wieck [EMAIL PROTECTED] writes:
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
Tom Lane wrote:
We've seen reports like this once or twice before, so I think that there
may indeed be some corner-case bug involved, but it's not going to be
possible to find it without a test case ... or at least a debuggable
core dump from the PANIC.
I just talked to the guy who sent the log
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 000A004B
LOG: recycled transaction log file 000A004D
LOG: recycled transaction log file
