Re: BUG #14150: Attempted to delete invisible tuple

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:48:06
Message-ID: CAM3SWZR95WJDjLp9gCpuT+jdPon2i0oO8ju_jV+eJtGzLSJwQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jul 6, 2016 at 5:22 PM, Peter Geoghegan <pg(at)heroku(dot)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 Content-Type Size
force-precheck.patch text/x-patch 1.2 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2016-07-07 00:58:53 Re: BUG #14232: Possible mistake in the documentation
Previous Message Thomas Munro 2016-07-07 00:25:22 Re: SELECT ... FOR UPDATE OF <table> SKIP LOCKED returns can same row when table is filtered on different table than locked