Re: BUG #14150: Attempted to delete invisible tuple
| От | Peter Tripp |
|---|---|
| Тема | Re: BUG #14150: Attempted to delete invisible tuple |
| Дата | |
| Msg-id | C5DBB6DE-6669-40B8-A3FF-218A513F8AA2@chartio.com обсуждение исходный текст |
| Ответ на | Re: BUG #14150: Attempted to delete invisible tuple (Peter Geoghegan <pg@heroku.com>) |
| Ответы |
Re: BUG #14150: Attempted to delete invisible tuple
|
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: