Date: Tue, 5 Jul 2022 09:58:38 -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: <20220705165838.GA1232533@nathanxps13>
References: <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>
 <20220502173907.GB3351307@nathanxps13>
 <20220502230613.GA3398932@nathanxps13>
 <YnOwioN/mo6k1Dtb@paquier.xyz>
 <YsORtfT4+fXj/i1V@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YsORtfT4+fXj/i1V@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/20220705165838.GA1232533%40nathanxps13>
Precedence: bulk

On Tue, Jul 05, 2022 at 10:19:49AM +0900, Michael Paquier wrote:
> On Thu, May 05, 2022 at 08:10:02PM +0900, Michael Paquier wrote:
>> I'd agree with removing all the callers at the end.  pgrename() is
>> quite robust on Windows, but I'd keep the two checks in
>> writeTimeLineHistory(), as the logic around findNewestTimeLine() would
>> consider a past TLI history file as in-use even if we have a crash
>> just after the file got created in the same path by the same standby,
>> and the WAL segment init part.  Your patch does that.
> 
> As v16 is now open for business, I have revisited this change and
> applied 0001 to change all the callers (aka removal of the assertion
> for the WAL receiver when it overwrites a TLI history file).  The
> commit log includes details about the reasoning of all the areas
> changed, for clarity, as of the WAL recycling part, the TLI history
> file part and basic_archive. 

Thanks!  I wonder if we should add a comment in writeTimeLineHistoryFile()
about possible concurrent use by a WAL receiver and the startup process and
why that is okay.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com