Re: Possible race condition in pg_mkdir_p()?

On Wed, Jul 31, 2019 at 1:31 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Jul 30, 2019 at 10:19:45PM -0700, Andres Freund wrote:
> > I don't really have a problem fixing this case if we think it's
> > useful. But I'm a bit bothered by all the "fixes" being submitted that
> > don't matter for PG itself. They do eat up resources.
>
> Sure.  In this particular case, we can simplify at least one code path
> in the backend though for temporary path creation.  Such cleanup rings
> like a sufficient argument to me.

Yes, in current postgres source code there are several wrappers of
mkdir() that do similar jobs.  If we could have a safe mkdir_p()
implementation then we could use it directly in all these wrappers, that
could save a lot of maintenance effort in the long run.  I'm not saying
that our patches are enough to make it safe and reliable, and I agree
that any patches may introduce new bugs, but I think that having a safe
and unified mkdir_p() is a good direction to go.

>
> > And sorry, adding in-backend threading to test testing mkdir_p doesn't
> > make me inclined to believe that this is all well considered.  There's
> > minor issues like us not supporting threads in the backend, pthread not
> > being portable, and also it being entirely out of proportion to the
> > issue.
>
> Agreed on this one.  The test case may be useful for the purpose of
> testing the presented patches, but it does not have enough value to be
> merged.

Yes, that's why we put the testing module in a separate patch from the
fix, feel free to ignore it.  In fact ourselves have concerns about it ;)

Best Regards
Ning

> --
> Michael