On Fri, Dec 30, 2022 at 11:57 PM Chong Wang <chongwa@vmware.com> wrote:
>
> I'm studying the source code about creation of initial logical decoding snapshot. What confused me is that why must
weprocess 3 xl_running_xacts before we get to the consistent state. I think we only need 2 xl_running_xacts.
>
> I think we can get to consistent state when we meet the 2nd xl_running_xact with its oldestRunningXid > 1st
xl_running_xact'snextXid, this means the active transactions in 1st xl_running_xact all had commited, and we have all
thelogs of transactions who will commit afterwards, so there is consistent state in this time point and we can export a
snapshot.
>
Yeah, we will have logs for all transactions in such a case but I
think we won't have a valid snapshot by that time. Consider a case
that there are two transactions 723,724 in the 2nd xl_running_xact
record for which we have waited to finish and then consider that point
as a consistent point and exported that snapshot. It is quite possible
that by that time the commit record of one or more of those xacts (say
724) wouldn't have been encountered by decoding process and that means
it won't be recorded in the xip list of the snapshot (we do that in
DecodeCommit->SnapBuildCommitTxn). So, during export in function
SnapBuildInitialSnapshot(), we will consider 723 as committed and 724
as running. This could not lead to inconsistent data on the client
side that imports such a snapshot and use it for copy and further
replicating the other xacts.
OTOH, currently, before marking snapshot state as consistent we wait
for these xacts to finish and for another xl_running_xact where
oldestRunningXid >= builder->next_phase_at to appear which means the
commit for both 723 and 724 would have appeared in the snapshot.
Does that makes sense to you or am, I missing something here?
--
With Regards,
Amit Kapila.
