RE: Logical replication timeout problem - Mailing list pgsql-hackers

From kuroda.hayato@fujitsu.com
Subject RE: Logical replication timeout problem
Date
Msg-id TYAPR01MB58661389F731CDA758E6F1F2F5099@TYAPR01MB5866.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Logical replication timeout problem  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
Responses RE: Logical replication timeout problem  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
List pgsql-hackers
Dear Wang,

Thank you for updating the patch! Good self-reviewing.

> And I looked into the function WalSndUpdateProgress. I found function
> WalSndUpdateProgress try to record the time of some message(by function
> LagTrackerWrite) sent to subscriber, such as in function pgoutput_commit_txn.

Yeah, I think you are right.

> Then, when publisher receives the reply message from the subscriber(function
> ProcessStandbyReplyMessage), publisher invokes LagTrackerRead to calculate
> the
> delay time(refer to view pg_stat_replication).
> Referring to the purpose of LagTrackerWrite, I think it is no need to log time
> when sending keepalive messages here.
> So when the parameter send_keep_alive of function WalSndUpdateProgress is
> true,
> skip the recording time.

I also read them. LagTracker records the elapsed time between sending commit
from publisher and receiving reply from subscriber, right? It seems good.

Do we need adding a test for them? I think it can be added to 100_bugs.pl.
Actually I tried to send PoC, but it does not finish to implement that.
I'll send if it is done.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Optionally automatically disable logical replication subscriptions on error
Next
From: Jeevan Ladhe
Date:
Subject: Re: refactoring basebackup.c