On Tue, Dec 1, 2020 at 6:26 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > One idea could be that the subscriber skips the transaction if it sees > > the transaction is already prepared. > > > > To skip it, we need to send GID in begin message and then on > subscriber-side, check if the prepared xact already exists, if so then > set a flag. The flag needs to be set in begin/start_stream and reset > in stop_stream/commit/abort. Using the flag, we can skip the entire > contents of the prepared xact. In ReorderFuffer-side also, we need to > get and set GID in txn even when we skip it because we need to send > the same at commit time. In this solution, we won't be able to send it > during normal start_stream because by that time we won't know GID and > I think that won't be required. Note that this is only required when > we skipped sending prepare, otherwise, we just need to send > Commit-Prepared at commit time. >
After going through both the solutions, I think the above one is a better idea. I also think, rather than change the protocol for the regular begin, we could have a special begin_prepare for prepared txns specifically. This way we won't affect non-prepared transactions. We will need to add in a begin_prepare callback as well, which has the gid as one of the parameters. Other than this, in ReorderBufferFinishPrepared, if the txn hasn't already been prepared (because it was skipped in DecodePrepare), then we set prepared flag and call ReorderBufferReplay before calling commit-prepared callback. At the subscriber side, on receipt of the special begin-prepare, we first check if the gid is of an already prepared txn, if yes, then we set a flag such that the rest of the transaction are not applied but skipped, If it's not a gid that has already been prepared, then continue to apply changes as you would otherwise. So, this is the approach I'd pick. The drawback is probably that we send extra prepares after a restart, which might be quite common while using test_decoding but not so common when using the pgoutput and real world scenarios of pub/sub. The second approach is a bit more involved requiring file creation and manipulation as well as the overhead of having to write to a file on every prepare which might be a performance bottleneck. Let me know what you think. regards, Ajin Cherian Fujitsu Australia
