Hi,
On 2019-06-11 11:47:07 -0400, Robert Haas wrote:
> On Wed, Aug 17, 2016 at 8:06 PM Andres Freund <andres@anarazel.de> wrote:
> > This commit updates the heap_abort_speculative() function which aborts
> > the conflicting tuple to use itself, via toast_delete, for deleting
> > associated TOAST datums. Like before, the inserted toast rows are not
> > marked as being speculative.
>
> I just noticed how crazy this is - not the commit itself
> (07ef035129586ca26a713c4cd15e550dfe35e643) but the thing which the
> commit message describes as pre-existing behavior. Apparently, even
> if the insertion wasn't speculative, you can still abort it just as if
> it had been, at least when we're talking about a TOAST table row. Not
> that I have a better idea, but are we sure that's the way we want to
> go?
Well, less "we want to go", and more "have been going for ~five
years"...
I don't think I immediately see - or saw back then - a realistic better
approach. I guess we could add a flag that somehow signals that a plain
delete should accept an invisible tuple as input, but that seems
dangerous too.
> This is relevant to my little project to make the TOAST logic reusable
> by other AMs, because the comments in tableam.h suggest you can only
> complete a speculative insertion if you've previously performed one.
> If we allow any AM to be used to implement a TOAST table, then it
> needs to be documented that such AMs have to cope with this kind of
> case.
Hm - you're thinking of making the case of toast AM and main AM being
different working? I'm not sure I'd otherwise expect to again go through
the AM, although I'm not sure about that.
Greetings,
Andres Freund