RE: Logical replication timeout problem
От | kuroda.hayato@fujitsu.com |
---|---|
Тема | RE: Logical replication timeout problem |
Дата | |
Msg-id | TYAPR01MB58661389F731CDA758E6F1F2F5099@TYAPR01MB5866.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Logical replication timeout problem ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>) |
Ответы |
RE: Logical replication timeout problem
|
Список | 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 по дате отправления: