Re: Helper functions for wait_for_catchup() in Cluster.pm
От | Drouvot, Bertrand |
---|---|
Тема | Re: Helper functions for wait_for_catchup() in Cluster.pm |
Дата | |
Msg-id | e8a56fac-2f23-141c-d9a5-731fd01115b2@gmail.com обсуждение исходный текст |
Ответ на | Re: Helper functions for wait_for_catchup() in Cluster.pm (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Helper functions for wait_for_catchup() in Cluster.pm
|
Список | pgsql-hackers |
Hi, On 1/17/23 12:23 PM, Alvaro Herrera wrote: > On 2023-Jan-17, Drouvot, Bertrand wrote: > >> The idea has been raised in [1], where we are adding more calls to >> wait_for_catchup() in 'replay' mode. > > This seems mostly useless as presented. Maybe if you're able to reduce > the noise on the second argument it would be worth something -- namely, > if the wrapper function receives a node instead of an LSN: perhaps > wait_for_replay_catchup() would use the flush LSN from the given node, > wait_for_write_catchup() would use the write LSN, and > wait_for_sent_catchup() would use the insert LSN. (I didn't check in > your patch if there are callsites that do something else). This would > in several cases let you also remove the line with the assignment of > appropriate LSN to a separate variable. If you did it that way, maybe > the code would become a tiny bit smaller overall. > Thanks for looking at it! The current calls are done that way: wait_for_replay_catchup called: - 8 times with write LSN as an argument - 1 time with insert LSN as an argument - 16 times with flush LSN as an argument wait_for_write_catchup called: - 5 times with write LSN as an argument So it looks like that providing a node as a second argument would not help for the wait_for_replay_catchup() case. Worth to use the node as an argument for wait_for_write_catchup()? (though it would be weird to have different types of arguments between wait_for_replay_catchup() and wait_for_write_catchup()). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: