On 1/26/22 16:17, Robert Haas wrote > 3. fairywren failed the last run in module-commit_tsCheck. It's unhappy > because: > > [16:30:02] t/002_standby.pl .... ok 13354 ms ( 0.06 usr 0.00 sys + > 1.11 cusr 3.20 csys = 4.37 CPU) > # poll_query_until timed out executing this query: > # SELECT '0/303C7D0'::pg_lsn <= pg_last_wal_replay_lsn() > # expecting this output: > # t > # last actual query output: > # f > > I don't know what is causing any of these failures, and I don't know > if there's already some discussion elsewhere that I've missed, but > maybe this email will be helpful to someone. I also noticed that 2 out > of the 3 failures report 2dbb7b9b2279d064f66ce9008869fd0e2b794534 "Fix > pg_hba_file_rules for authentication method cert" as the only new > commit since the last run, and it's hardly believable that that commit > would have broken this. Nor do I see any other recent changes that > look like likely culprits. Apologies in advance if any of this is my > fault. >
Intermittent failures give a false positive against the latest set of commits. These failures started happening regularly about 49 days ago. So we need to look at what exactly happened around then. See <https://buildfarm.postgresql.org/cgi-bin/show_failures.pl?max_days=90&stage=module-commit_tsCheck&filter=Submit> It's very unlikely any of this is your fault. In any case, intermittent failures are very hard to nail down. I should add that both drongo and fairywren run on a single AWS/EC2/Windows2019 instance. I haven't updated the OS in a while. so I'm doing that to see if matters improve. FWIW. I just reproduced the error on a similar instance where I'm testing some stuff for Andres' project to make TAP tests more portable. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com