On 04/15/2015 06:01 PM, Andres Freund wrote:
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.
Hmm, ok, I've read the "INSERT ... ON CONFLICT UPDATE and logical
decoding" thread now, and I have to say that IMHO it's a lot more sane
to handle this in ReorderBufferCommit() like Peter first did, than to
make the main insertion path more complex like this.
Another idea is to never spill the latest record to disk, at least if it
was a speculative insertion. Then you would be sure that when you see
the super-deletion record, the speculative insertion it refers to is
still in memory. That seems simple.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
