Re: BUG #14150: Attempted to delete invisible tuple - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: BUG #14150: Attempted to delete invisible tuple
Date
Msg-id CAM3SWZR95WJDjLp9gCpuT+jdPon2i0oO8ju_jV+eJtGzLSJwQg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14150: Attempted to delete invisible tuple  (Peter Geoghegan <pg@heroku.com>)
List pgsql-bugs
On Wed, Jul 6, 2016 at 5:22 PM, Peter Geoghegan <pg@heroku.com> wrote:
> The reason I doubted that it could be that simple was that it took
> this long to hear about this bug. It also took me a little while to
> produce a test case. I tended to doubt that all toast_delete() calls
> from heap_abort_speculative() are broken, since ISTM that they're not
> very rare in practice.
>
> I may have been wrong about that, though.

Looks like I was wrong about that. Attached simple patch forces the
implementation to see no conflict when the precheck is attempted in
the first iteration. It artificially forces a conflict. This causes
the regression tests to fail in one or two places, because an error is
raised in the INSERT path that would never have been reached otherwise
(e.g. there is a second almost equivalent unique that ON CONFLICT did
not infer).

These regression test failures are not interesting, though. What is
interesting is that the "attempted to delete invisible tuple" error
can be seen in a single interactive psql session once the patch is
applied. So, there is no race condition as such at all.

--
Peter Geoghegan

Attachment

pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: SELECT ... FOR UPDATE OF SKIP LOCKED returns can same row when table is filtered on different table than locked
Next
From: aouda.h@me.com
Date:
Subject: BUG #14232: Possible mistake in the documentation