Re: Possible race condition in pg_mkdir_p()?

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

In response to

Browse pgsql-hackers by date

  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