On 3 February 2017 at 03:34, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Feb 1, 2017 at 4:35 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: >> Right. Per my comments uothread I don't see why we need to add anything more >> to WAL here. >> >> Stas was concerned about what happens in logical decoding if we crash >> between PREPSRE TRANSACTION and COMMIT PREPARED. But we'll always go back >> and decode the whole txn again anyway so it doesn't matter. >> >> We can just track it on ReorderBufferTxn when we see it at PREPARE >> TRANSACTION time. > > Oh, hmm. I guess if that's how it works then we don't need it in WAL > after all. I'm not sure that re-decoding the already-prepared > transaction is a very good plan, but if that's what we're doing anyway > this patch probably shouldn't change it.
We don't have much choice at the moment. Logical decoding must restart from the xl_running_xacts most recently prior to the xid allocation for the oldest xact the client hasn't confirmed receipt of decoded data + commit for. That's because reorder buffers are not persistent; if a decoding session crashes we throw away accumulated reorder buffers, both those in memory and those spilled to disk. We have to re-create them by restarting decoding from the beginning of the oldest xact of interest. We could make reorder buffers persistent and shared between decoding sessions but it'd totally change the logical decoding model and create some other problems. It's certainly not a topic for this patch. So we can take it as given that we'll always restart decoding from BEGIN again at a crash. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
