Re: Possible race condition in pg_mkdir_p()? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Possible race condition in pg_mkdir_p()?
Date
Msg-id 20190731044823.GM1577@paquier.xyz
Whole thread Raw
In response to Re: Possible race condition in pg_mkdir_p()?  (Andres Freund <andres@anarazel.de>)
Responses Re: Possible race condition in pg_mkdir_p()?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Jul 30, 2019 at 09:11:44PM -0700, Andres Freund wrote:
> Hm. I'm not really seing much of a point in making mkdir_p safe against
> all of this. What's the scenario for pg where this matters? I assume
> you're using it for somewhat different purposes, and that's why it is
> problematic for you?

I don't see why it is a problem to make our APIs more stable if we
have ways to do so.  I actually fixed one recently as of 754b90f for a
problem that involved a tool linking to our version of readdir() that
we ship.  Even with that, the retries for mkdir() on the base
directory in PathNameCreateTemporaryDir() are basically caused by that
same limitation with the parent paths from this report, no?  So we
could actually remove the dependency to the base directory in this
code path and just rely on pg_mkdir_p() to do the right thing for all
the parent paths.  That's also a point raised by Ning upthread.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs
Next
From: Ning Yu
Date:
Subject: Re: Possible race condition in pg_mkdir_p()?