Re: "Multiple table synchronizations are processed serially" still happens - Mailing list pgsql-hackers

From Guillaume Lelarge
Subject Re: "Multiple table synchronizations are processed serially" still happens
Date
Msg-id CAECtzeVtn0H8GNEFZKi-Cpf3LXE6BL1neDVNCMrskdidA59bsA@mail.gmail.com
Whole thread Raw
In response to Re: "Multiple table synchronizations are processed serially" still happens  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: "Multiple table synchronizations are processed serially" still happens
List pgsql-hackers
Le ven. 21 mai 2021 à 05:43, Amit Kapila <amit.kapila16@gmail.com> a écrit :
On Fri, May 21, 2021 at 1:30 AM Guillaume Lelarge
<guillaume@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.
 
, 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?

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.


--
Guillaume.

pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Forget close an open relation in ReorderBufferProcessTXN()
Next
From: Tom Lane
Date:
Subject: Re: Installation of regress.so?