Re: BUG #14150: Attempted to delete invisible tuple

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

In response to

Responses

Browse pgsql-bugs by date

  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