On Mon, May 02, 2022 at 07:48:18PM +0900, Michael Paquier wrote: > Skimming through at the buildfarm logs, it happens that the tests are > able to see this race from time to time. Here is one such example on > rorqual: > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2022-04-20%2004%3A47%3A58&stg=recovery-check > > And here are the relevant logs: > 2022-04-20 05:04:19.028 UTC [3109048][startup][:0] LOG: restored log > file "00000002.history" from archive > 2022-04-20 05:04:19.029 UTC [3109111][walreceiver][:0] LOG: fetching > timeline history file for timeline 2 from primary server > 2022-04-20 05:04:19.048 UTC [3109111][walreceiver][:0] FATAL: could > not link file "pg_wal/xlogtemp.3109111" to "pg_wal/00000002.history": > File exists > [...] > 2022-04-20 05:04:19.234 UTC [3109250][walreceiver][:0] LOG: started > streaming WAL from primary at 0/3000000 on timeline 2 > > The WAL receiver upgrades the ERROR to a FATAL, and restarts > streaming shortly after. Using durable_rename() would not be an issue > here.
Thanks for investigating this one. I think I agree that we should simply switch to durable_rename() (without a file existence check beforehand). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
