| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Oskari Saarenmaa <os(at)aiven(dot)io>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Tripp <peter(at)chartio(dot)com>, Virendra Negi <virendra(at)idyllic-software(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14150: Attempted to delete invisible tuple |
| Date: | 2016-07-07 00:14:30 |
| Message-ID: | CAM3SWZSN9Dinfr+pujH5RHwycWgT68pkypYs5MUY2u2EjrN6tg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jul 6, 2016 at 4:33 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> We didn't simply neglect to make heap_abort_speculative() consider
>> TOAST at all, though.
>
> Well, not quite, but nearly. Afaics it currently can only work if the
> toasted columns have been inserted by a different command, before the
> INSERT ON CONFLICT does anything. I don't see how it can work for newly
> inserted toast data. When heap_abort_speculative deletes toast data,
> when would it *ever* not fail if the same command executed the toast
> data?
Why would the toasted data ever not be newly inserted in practice? Do
you mean that that would work, where it ever to occur, though in
practice it could not, since this concerns only cases that take the
path with heap_insert()? And so, in simpler words, you believe that
any heap_abort_speculative() call to toast_delete() will cause this
error to be raised?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-07-07 00:15:32 | Re: BUG #14150: Attempted to delete invisible tuple |
| Previous Message | aouda.h | 2016-07-06 23:46:54 | BUG #14232: Possible mistake in the documentation |