From: | Ning Yu <nyu(at)pivotal(dot)io> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | 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:35:02 |
Message-ID: | CAKmaiL2DmssMdEpTyZRShX+-7uTOXhT3910PTr5c0MbhQdRPtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 31, 2019 at 12:11 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2019-07-18 16:17:22 +0800, Ning Yu wrote:
> > This seems buggy as it first checks the existence of the dir and makes the
> > dir if it does not exist yet, however when executing concurrently a
> > possible race condition can be as below:
> >
> > A: does a/ exists? no
> > B: does a/ exists? no
> > A: try to create a/, succeed
> > B: try to create a/, failed as it already exists
>
> 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?
Yes, you are right, postgres itself might not run into such kind of race
condition issue. The problem we encountered was on a downstream product
of postgres, where multiple postgres clusters are deployed on the same
machine with common parent dirs.
Best Regards
Ning
>
> Greetings,
>
> Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-07-31 04:40:54 | Re: Possible race condition in pg_mkdir_p()? |
Previous Message | Tom Lane | 2019-07-31 04:30:46 | Re: SegFault on 9.6.14 |