Re: Race conditions with TAP test for syncrep

2019-07-23 Thread Michael Paquier
On Tue, Jul 23, 2019 at 05:04:32PM +0900, Michael Paquier wrote: > Thanks Noah for the review. I have reviewed the thread and improved a > couple of comments based on Alvaro's previous input. Attached is v2. > If there are no objections, I would be fine to commit it. Applied and back-patched dow

Re: Race conditions with TAP test for syncrep

2019-07-23 Thread Michael Paquier
On Mon, Jul 22, 2019 at 11:45:53PM -0700, Noah Misch wrote: > PostgresNode uses "print" the same way. The patch does close the intended > race conditions, and its implementation choices look fine to me. Thanks Noah for the review. I have reviewed the thread and improved a couple of comments base

Re: Race conditions with TAP test for syncrep

2019-07-22 Thread Noah Misch
On Tue, Jun 18, 2019 at 09:59:08AM +0900, Michael Paquier wrote: > On Mon, Jun 17, 2019 at 10:50:39AM -0400, Alvaro Herrera wrote: > > I think this should be note() rather than print(), or maybe diag(). (I > > see that we have a couple of other cases which use print() in the tap > > tests, which I

Re: Race conditions with TAP test for syncrep

2019-06-19 Thread Michael Paquier
On Wed, Jun 19, 2019 at 04:08:44PM -0400, Alvaro Herrera wrote: > Ho ho .. you know what misled me into thinking that that would work? > Just look at the name of the test that failed, "asterisk comes before > another standby name". That doesn't seem to be what the test is > testing! I agree that

Re: Race conditions with TAP test for syncrep

2019-06-19 Thread Alvaro Herrera
On 2019-Jun-18, Michael Paquier wrote: > On Mon, Jun 17, 2019 at 10:50:39AM -0400, Alvaro Herrera wrote: > > Hmm, this introduces a bit of latency: it waits for each standby to be > > fully up before initializing the next standby. Maybe it would be more > > convenient to split the primitives: kee

Re: Race conditions with TAP test for syncrep

2019-06-17 Thread Michael Paquier
On Mon, Jun 17, 2019 at 10:50:39AM -0400, Alvaro Herrera wrote: > Hmm, this introduces a bit of latency: it waits for each standby to be > fully up before initializing the next standby. Maybe it would be more > convenient to split the primitives: keep the current one to start the > standby, and ad

Re: Race conditions with TAP test for syncrep

2019-06-17 Thread Alvaro Herrera
On 2019-Jun-17, Michael Paquier wrote: > 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.

Race conditions with TAP test for syncrep

2019-06-16 Thread Michael Paquier
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.gc1...@paquier.xyz The buildfarm failure is here: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2019-05-