Re: BUG #14150: Attempted to delete invisible tuple

From: Andres Freund <andres(at)anarazel(dot)de>
To: Oskari Saarenmaa <os(at)aiven(dot)io>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, 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(at)postgresql(dot)org
Subject: Re: BUG #14150: Attempted to delete invisible tuple
Date: 2016-08-18 00:09:32
Message-ID: 20160818000932.5ugispgqu3iw3g54@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2016-08-06 00:37:08 +0300, Oskari Saarenmaa wrote:
> 01.08.2016, 01:31, Andres Freund kirjoitti:
> > On 2016-07-29 17:37:21 -0700, Peter Geoghegan wrote:
> > > On Wed, Jul 27, 2016 at 6:12 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> > > > On Wed, Jul 27, 2016 at 6:04 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > > That it needs a test, or that it's easy to do?
> > > >
> > > > That it's easy to write one.
> > >
> > > I'll be more concrete: I don't see what choke point is available to
> > > make control yield after the pre-check determines there is no
> > > conflict, but before index tuple insertion determines that there is in
> > > fact a conflict (to reliably trigger a failed specualtive
> > > insertion/super deletion).
> >
> > An expression index over a function acquiring a lock looks like it
> > should do the trick.
> >
> > Are you looking in writing an updated patch? It seems we're on one page
> > of the rough direction.
>
> Thanks for the review and the locking index idea for a test case. Attached a
> further simplified patch to fix the issue plus an isolation test case for
> it.

Thanks.

I pushed a lightly editorialized version of this. The changes primarily
were around the regression test:

1) The test originally hung for me every few executions - there's no
guarantee whether s2 or s3 gets to run first. Removing the
transaction from the inserting xacts should do the trick.
2) The random function doesn't actually return anything random.
3) I thought the test needed some explanation.

Unfortunately the test doesn't work on <9.6 (no way to wait for two
blocked sessions back then), so I had to remove the tests for 9.5.

Regards,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2016-08-18 00:25:54 Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
Previous Message Andres Freund 2016-08-17 20:23:38 Re: BUG #14228: replication slot catalog_xmin not cleared on slot reuse