From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: terminated by signal 6 problem |
Date: | 2004-08-11 21:22:29 |
Message-ID: | 18873.1092259349@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)com> 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 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.
Sure it is. _bt_insertonpg is holding an exclusive lock on the page
the entire time.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-08-11 21:43:44 | Re: terminated by signal 6 problem |
Previous Message | Joe Conway | 2004-08-11 20:54:30 | Re: terminated by signal 6 problem |