Race conditions with TAP test for syncrep
От
Michael Paquier
Тема
Race conditions with TAP test for syncrep
Дата
Msg-id
20190617055145.GB18917@paquier.xyz
Список
Дерево обсуждения
Race conditions with TAP test for syncrep Michael Paquier <michael@paquier.xyz>
Re: Race conditions with TAP test for syncrep Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Race conditions with TAP test for syncrep Michael Paquier <michael@paquier.xyz>
Re: Race conditions with TAP test for syncrep Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Race conditions with TAP test for syncrep Michael Paquier <michael@paquier.xyz>
Re: Race conditions with TAP test for syncrep Noah Misch <noah@leadboat.com>
Re: Race conditions with TAP test for syncrep Michael Paquier <michael@paquier.xyz>
Re: Race conditions with TAP test for syncrep Michael Paquier <michael@paquier.xyz>
Hi all, Alvaro has reported a rather rare buildfarm failure involving 007_sync_rep.pl to which I have responded here: https://www.postgresql.org/message-id/20190613060123.GC1643@paquier.xyz The buildfarm failure is here: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2019-05-12%2020%3A37%3A11 It involves a race condition related to the way the standbys of the test are stopped and restarted to ensure that they appear in the correct order in the WAL sender array of the primary, but feel free to look at the message above for all the details. Attached is a patch to improve the stability of the test. The fix I am proposing is very simple: in order to make sure that a standby is added into the WAL sender array of the primary, let's check after pg_stat_replication after a standby is started. This can be done consistently with a small wrapper in the tests. Any thoughts? -- Michael
В списке pgsql-hackers по дате отправления