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 |
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 |