On 2016-07-06 16:07:38 -0700, Peter Geoghegan wrote:
> On Wed, Jul 6, 2016 at 3:30 AM, Oskari Saarenmaa <os@aiven.io> wrote:
> >> ISTM this is caused by toast knowing nothing about speculative
> >> insertion: when two backends have executed a speculative heap_insert
> >> with a conflicting key and the latter one tries to abort after receiving
> >> specConflict there's nothing in tqual.c to say that the toast rows
> >> associated with speculative insertion should be visible to that operation.
> >
> >
> > The attached patch against current master allows heap_abort_speculative to
> > delete toast rows created by the same command which makes the above test
> > case and "make check" run without failures. Note that I haven't touched
> > this code before so I don't know how safe my patch is.
>
> I don't really understand your explanation of what this patch does.
> Obviously heap_abort_speculative() often has no apparent problem with
> any of this; this bug involves a relatively rare race condition
> scenario where there *is* a problem.
Did you see oskari's reproducer in
http://archives.postgresql.org/message-id/88248a24-47d1-d575-a63f-2b56a09f82e2%40aiven.io
?
It's not really particularly hard to reproduce with that (pretty basic
interaction). Works like in 80% of the cases I tried, within less than a
sec.
> We didn't simply neglect to make heap_abort_speculative() consider
> TOAST at all, though.
Well, not quite, but nearly. Afaics it currently can only work if the
toasted columns have been inserted by a different command, before the
INSERT ON CONFLICT does anything. I don't see how it can work for newly
inserted toast data. When heap_abort_speculative deletes toast data,
when would it *ever* not fail if the same command executed the toast
data?
Andres