Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On 2015-04-15 17:58:54 +0300, Heikki Linnakangas wrote:
> On 04/15/2015 07:51 AM, Peter Geoghegan wrote:
> >+heap_finish_speculative(Relation relation, HeapTuple tuple, bool conflict)
> >+{
> >+    if (!conflict)
> >+    {
> >+        /*
> >+         * Update the tuple in-place, in the common case where no conflict was
> >+         * detected during speculative insertion.
> >+         *
> >+         * When heap_insert is called in respect of a speculative tuple, the
> >+         * page will actually have a tuple inserted.  However, during recovery
> >+         * replay will add an all-zero tuple to the page instead, which is the
> >+         * same length as the original (but the tuple header is still WAL
> >+         * logged and will still be restored at that point).  If and when the
> >+         * in-place update record corresponding to releasing a value lock is
> >+         * replayed, crash recovery takes the final tuple value from there.
> >+         * Thus, speculative heap records require two WAL records.
> >+         *
> >+         * Logical decoding interprets an in-place update associated with a
> >+         * speculative insertion as a regular insert change.  In other words,
> >+         * the in-place record generated affirms that a speculative insertion
> >+         * completed successfully.
> >+         */
> >+        heap_inplace_update(relation, tuple);
> >+    }
> >+    else
> >+    {
> 
> That's a bizarre solution.

I tend to agree, but for different reasons.

> In logical decoding, decode speculative insertions like any other insertion.
> To decode a super-deletion record, scan the reorder buffer for the
> transaction to find the corresponding speculative insertion record for the
> tuple, and remove it.

Not that easy. That buffer is spilled to disk and such. As discussed.

Greetings,

Andres Freund