Re: "Multiple table synchronizations are processed serially" still happens

On Fri, May 21, 2021 at 6:47 PM Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
>
> Le ven. 21 mai 2021 à 05:43, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> a écrit :
>>
>> On Fri, May 21, 2021 at 1:30 AM Guillaume Lelarge
>> <guillaume(at)lelarge(dot)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.