Re: Possible race condition in pg_mkdir_p()?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Ning Yu <nyu(at)pivotal(dot)io>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Paul Guo <pguo(at)pivotal(dot)io>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Possible race condition in pg_mkdir_p()?
Date: 2019-07-31 04:48:23
Message-ID: 20190731044823.GM1577@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ning Yu 2019-07-31 04:48:48 Re: Possible race condition in pg_mkdir_p()?
Previous Message Amit Kapila 2019-07-31 04:43:26 Re: POC: Cleaning up orphaned files using undo logs