Re: repeated decoding of prepared transactions

On 20.02.21 04:38, Amit Kapila wrote:
> I see a problem with this assumption. During the initial
> synchronization, this transaction won't be visible to snapshot and we
> won't copy it. Then later if we won't decode and send it then the
> replica will be out of sync. Such a problem won't happen with Ajin's
> patch.

You are assuming that the initial snapshot is a) logical and b) dumb.

A physical snapshot very well "sees" prepared transactions and will 
restore them to their prepared state.  But even in the logical case, I 
think it's beneficial to keep the decoder simpler and instead require 
some support for two-phase commit in the initial synchronization logic. 
  For example using the following approach (you will recognize 
similarities to what snapbuild does):

1.) create the slot
2.) start to retrieve changes and queue them
3.) wait for the prepared transactions that were pending at the
     point in time of step 1 to complete
4.) take a snapshot (by visibility, w/o requiring to "see" prepared
     transactions)
5.) apply the snapshot
6.) replay the queue, filtering commits already visible in the
     snapshot

Just as with the solution proposed by Ajin and you, this has the danger 
of showing transactions as committed without the effects of the PREPAREs 
being "visible" (after step 5 but before 6).

However, this approach of solving the problem outside of the walsender 
has two advantages:

* The delay in step 3 can be made visible and dealt with.  As there's
   no upper boundary to that delay, it makes sense to e.g. inform the
   user after 10 minutes and provide a list of two-phase transactions
   still in progress.

* Second, it becomes possible to avoid inconsistencies during the
   reconciliation window in between steps 5 and 6 by disallowing
   concurrent (user) transactions to run until after completion of
   step 6.

Whereas the current implementation hides this in the walsender without 
any way to determine how much a PREPARE had been delayed or when 
consistency has been reached.  (Of course, short of using the very same 
initial snapshotting approach outlined above.  For which the reordering 
logic in the walsender does more harm than good.)

Essentially, I think I'm saying that while I agree that some kind of 
snapshot synchronization logic is needed, it should live in a different 
place.

Regards

Markus