Re: BUG #14150: Attempted to delete invisible tuple

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@heroku.com> wrote:
> > > > On Wed, Jul 27, 2016 at 6:04 PM, Andres Freund <andres@anarazel.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