On Fri, Dec 30, 2022 at 11:57 PM Chong Wang <chon...@vmware.com> wrote: > > I'm studying the source code about creation of initial logical decoding > snapshot. What confused me is that why must we process 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's nextXid, this means the > active transactions in 1st xl_running_xact all had commited, and we have all > the logs 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.
