On Sat, Apr 2, 2022 at 5:47 AM Tomas Vondra
<tomas.vondra@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.
