Re: [HACKERS] Multiple table synchronizations are processed serially - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] Multiple table synchronizations are processed serially
Date
Msg-id CAD21AoARBMCTL9UX2S=U5D3wwe7HqiPicBH+cCT05JeokLQBfg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Multiple table synchronizations are processed serially  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Sat, May 20, 2017 at 4:47 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 5/19/17 01:01, Masahiko Sawada wrote:
>> Seems all four table sync workers are launched at the almost same
>> time, but three workers of them get stuck in idle transaction state
>> when creating replication slot. That is these waiting workers cannot
>> proceed its work until first connected table sync worker finishes. ps
>> command shows the followings.
>
> Creating a replication slot waits for all transactions to finish.  So if
> one of those transactions is a table copy of another subscription, it
> has to wait for that.
>
> You can avoid that by creating all the slots first and then triggering
> the initial table copy separately.
>

Thank you for suggestion!
I understood the reason why subsequent processes have to wait. If some
of tables belonging to publication are very large, the idle
transaction will wait for a long time, which is not good. So as you
mentioned it seems to me that it's better to create all slots first
and then trigger the initial table copy separately especially in such
case.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: [HACKERS] Fix a typo in hash.c
Next
From: Beena Emerson
Date:
Subject: [HACKERS] Default Partition for Range