From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
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 05:19:45 |
Message-ID: | 20190731051945.vvqpjhvh3bze5jdp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-07-31 13:48:23 +0900, Michael Paquier wrote:
> 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.
Well, wanting to support additional use-cases often isn't free. There's
additional code for the new usecase, there's review & commit time,
there's additional test time, there's bug fixes for the new code etc.
We're not developing a general application support library...
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.
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-07-31 05:31:39 | Re: Possible race condition in pg_mkdir_p()? |
Previous Message | Craig Ringer | 2019-07-31 05:08:12 | Re: tap tests driving the database via psql |