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

Поиск
Список
Период
Сортировка
От Guillaume Lelarge
Тема Re: "Multiple table synchronizations are processed serially" still happens
Дата
Msg-id CAECtzeVtn0H8GNEFZKi-Cpf3LXE6BL1neDVNCMrskdidA59bsA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: "Multiple table synchronizations are processed serially" still happens  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: "Multiple table synchronizations are processed serially" still happens  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Forget close an open relation in ReorderBufferProcessTXN()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Installation of regress.so?