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 fil
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 r
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
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
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 fi