On Fri, May 21, 2021 at 6:47 PM Guillaume Lelarge <guilla...@lelarge.info> wrote: > > Le ven. 21 mai 2021 à 05:43, Amit Kapila <amit.kapil...@gmail.com> a écrit : >> >> On Fri, May 21, 2021 at 1:30 AM Guillaume Lelarge >> <guilla...@lelarge.info> wrote: >> > >> > >> >> If so, the >> >> problem might be that copying the data of the first table creates a >> >> transaction which blocks creation of the slot for second table copy. >> > >> > >> > I don't understand how a transaction could block the creation of a slot. >> > Could you explain that to me? >> > >> >> During the creation of the slot > > > During the creation of the slot or during the creation of the subscription? > because, in my tests, I create the slot before creating the snapshot. >
But we do internally create another slot for tablesync via a tablesync-worker that does the initial copy. >> >> , we need to build the initial snapshot >> which is used for decoding WAL. Now, to build the initial snapshot, we >> wait for all running xacts to finish. See functions >> CreateReplicationSlot() and SnapBuildFindSnapshot(). >> > > If we have two workers, both will have a snapshot? they don't share the same > snapshot? > No, for initial tablesync, we need to build a full snapshot (see use of CRS_USE_SNAPSHOT option in code). > And if all this is true, I don't see how it could work when the replication > happens between two clusters, and couldn't work when it happens with only one > cluster. > I think you might want to try this once. -- With Regards, Amit Kapila.
