There is no foreign key, but you are correct there is a codepath which can r=
esult in a delete statement being executed:
DELETE FROM cache WHERE key=3D
-Pete
>> On Jun 7, 2016, at 7:00 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>=20
>> On Tue, Jun 7, 2016 at 6:41 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> Does your test case also use foreign keys?
>=20
> 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.)
>=20
> 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.
>=20
> --=20
> Peter Geoghegan