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
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 |