Re: Logical replication keepalive flood

Поиск
Список
Период
Сортировка
От Abbas Butt
Тема Re: Logical replication keepalive flood
Дата
Msg-id CALtH27fYwe7MLbTQujwbp31=+Mef_+mMv9=g19Eg=xbmOhEsow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical replication keepalive flood  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Logical replication keepalive flood  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
Hi,

On Wed, Jun 9, 2021 at 2:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Wed, Jun 9, 2021 at 1:47 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Wed, 9 Jun 2021 11:21:55 +0900, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > The issue - if actually it is - we send a keep-alive packet before a
> > quite short sleep.
> >
> > We really want to send it if the sleep gets long but we cannot predict
> > that before entering a sleep.
> >
> > Let me think a little more on this..
>
> After some investigation, I find out that the keepalives are sent
> almost always after XLogSendLogical requests for the *next* record.
>

Does these keepalive messages are sent at the same frequency even for
subscribers?

Yes, I have tested it with one publisher and one subscriber.
The moment I start pgbench session I can see keepalive messages sent and replied by the subscriber with same frequency.
 
Basically, I wanted to check if we have logical
replication set up between 2 nodes then do we send these keep-alive
messages flood?

Yes we do.
 
If not, then why is it different in the case of
pg_recvlogical?

Nothing, the WAL sender behaviour is same in both cases.
 
Is it possible that the write/flush location is not
updated at the pace at which we expect?

Well, it is async replication. The receiver can choose to update LSNs at its own will, say after 10 mins interval.
It should only impact the size of WAL retained by the server.

Please see commit 41d5f8ad73
which seems to be talking about a similar problem.

That commit does not address this problem.
 

--
With Regards,
Amit Kapila.


--
--
Abbas
Senior Architect


Skype ID: gabbasb

Follow us on Twitter
@EnterpriseDB

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fdw batch insert error out when set batch_size > 65535