From: | Peter Tripp <peter(at)chartio(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14150: Attempted to delete invisible tuple |
Date: | 2016-06-08 04:09:47 |
Message-ID: | C5DBB6DE-6669-40B8-A3FF-218A513F8AA2@chartio.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
There is no foreign key, but you are correct there is a codepath which can result in a delete statement being executed:
DELETE FROM cache WHERE key=
-Pete
>> On Jun 7, 2016, at 7:00 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>>
>> 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 | Peter Geoghegan | 2016-06-08 04:23:58 | Re: BUG #14150: Attempted to delete invisible tuple |
Previous Message | Tom Lane | 2016-06-08 03:04:05 | Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all |