On Wed, Aug 17, 2016 at 8:06 PM Andres Freund <and...@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? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
