On Sat, Apr 2, 2022 at 5:47 AM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 4/1/22 17:02, Tomas Vondra wrote: > > The only option I see is reworking the decoding so that it does not need > the snapshot at all. We'll need to stash the changes just like any other > change, apply them at end of transaction, and the main difference > between transactional and non-transactional case would be what happens > at abort. Transactional changes would be discarded, non-transactional > would be applied anyway. >
I think in the above I am not following how we can make it work without considering *snapshot at all* because based on that we would have done the initial sync (copy_sequence) and if we don't follow that later it can lead to inconsistency. I might be missing something here. > The challenge is this reorders the sequence changes, so we'll need to > reconcile them somehow. One option would be to simply (1) apply the > change with the highest LSN in the transaction, and then walk all other > in-progress transactions and changes for that sequence with a lower LSN. > Not sure how complex/expensive that would be, though. Another problem is > not all increments are WAL-logged, of course, not sure about that. > > Another option might be revisiting the approach proposed by Hannu in > September [1], i.e. tracking sequences touched in a transaction, and > then replicating the current state at that particular moment. > I'll think about that approach as well. -- With Regards, Amit Kapila.
