Date: Mon, 18 Apr 2022 11:23:36 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: avoid multiple hard links to same WAL file after a crash
Message-ID: <20220418182336.GA2298576@nathanxps13>
References: <20220407182954.GA1231544@nathanxps13>
 <CA+TgmoZ5VHuv_BzpH7jrgyLu1Kymo=Xom5xFOeGf6xXP9BLhkQ@mail.gmail.com>
 <20220408165312.GB1409034@nathanxps13>
 <CA+Tgmobjke2TBrYk=Zmo=zawkG9A4saAwbe-O5wLHqY9Bz1Fag@mail.gmail.com>
 <Yl0X0+/9lcGzcIui@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yl0X0+/9lcGzcIui@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/20220418182336.GA2298576%40nathanxps13>
Precedence: bulk

On Mon, Apr 18, 2022 at 04:48:35PM +0900, Michael Paquier wrote:
> Saying that, it would be nice to see durable_rename_excl() gone as it
> has created quite a bit of pain for us in the past years.

Yeah, I think this is the right thing to do.  Patch upthread [0].

For back-branches, I suspect we'll want to remove all uses of
durable_rename_excl() but leave the function around for any extensions that
are using it.  Of course, we'd also need a big comment imploring folks not
to add any more callers.  Another option would be to change the behavior of
durable_rename_excl() to something that we think is safer (e.g., stat then
rename), but that might just introduce a different set of problems.

[0] https://postgr.es/m/20220408194345.GA1541826%40nathanxps13

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