Date: Mon, 2 May 2022 10:39:07 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, tgl@sss.pgh.pa.us,
	robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: avoid multiple hard links to same WAL file after a crash
Message-ID: <20220502173907.GB3351307@nathanxps13>
References: 
 <CA+TgmobGi7b-5fjAWgEO0ebn516n0OyOi-j7+Hyz_j9sAG17og@mail.gmail.com>
 <289699.1649694527@sss.pgh.pa.us>
 <20220411165257.GB1915258@nathanxps13>
 <20220412.154631.417529439388886590.horikyota.ntt@gmail.com>
 <20220412162742.GB2062175@nathanxps13>
 <Ym6GZbqQdlalSKSG@paquier.xyz>
 <Ym+28lDf5sCJ6pAj@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Ym+28lDf5sCJ6pAj@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/20220502173907.GB3351307%40nathanxps13>
Precedence: bulk

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