On Sun, Jul 31, 2022 at 3:46 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Sun, Jul 31, 2022 at 2:37 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > > > WFM, pushed that way. > > > > Looks like conchuela is still intermittently unhappy. > > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2022-07-30%2004%3A57%3A51 > > And here's one from CI that failed on Linux (this was a cfbot run with > an unrelated patch, parent commit b998196 so a few commits after "Fix > test instability"): > > https://cirrus-ci.com/task/5282155000496128 > > https://api.cirrus-ci.com/v1/artifact/task/5282155000496128/log/src/test/recovery/tmp_check/log/033_replay_tsp_drops_primary1_WAL_LOG.log > > It looks like this sequence is racy and we need to wait for more than > just "connection is made" before dropping the slot? > > $node_standby->start; > > # Make sure connection is made > $node_primary->poll_query_until('postgres', > 'SELECT count(*) = 1 FROM pg_stat_replication'); > $node_primary->safe_psql('postgres', "SELECT > pg_drop_replication_slot('slot')"); > > Why not set the replication slot name so that the standby uses it > "properly", like in other tests?
Or to keep doing it this way, does that pg_stat_replication query need a WHERE clause looking at the state?
