From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Peter Tripp <peter(at)chartio(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14150: Attempted to delete invisible tuple |
Date: | 2016-06-08 02:00:29 |
Message-ID: | CAM3SWZTEfeG3r2OibYFu_UQpC=8B328m2U=XCNc3bgP5UMYE7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Jun 7, 2016 at 6:41 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Does your test case also use foreign keys?
It's clearly in evidence that there is some kind of delete involved
here, possibly from a cascading foreign key. That's because the error
message "attempted to delete invisible tuple" is not one that is
reachable from a simple ON CONFLICT DO UPDATE. (Yes, it's true that
heap_abort_speculative() performs something pretty close when there's
lots of concurrency -- it performs what I've called a "super deletion"
-- but its equivalent "can't happen" error message is not what we see
here.)
So, if it's not coming from a cascading foreign key, as I suspect,
then it's definitely coming from some other user-visible delete
(Something that can reach heap_delete(), very probably through
ExecDelete()). I'm very curious about what that is.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-08 02:07:28 | Re: [BUGS] BUG #14155: bloom index error with unlogged table |
Previous Message | Peter Geoghegan | 2016-06-08 01:41:41 | Re: BUG #14150: Attempted to delete invisible tuple |