Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres
Date: 2021-04-12 05:25:53
Message-ID: YHPZ4WDnCxhOUVLz@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, Apr 09, 2021 at 08:07:10PM -0700, Noah Misch wrote:
> "pg_regress --outputdir" is not a great location for a file or directory
> created by a user other than the user running pg_regress. If one does "make
> check" and then "make installcheck" against a cluster running as a different
> user, the rmtree() will fail, assuming typical umask values. An rmtree() at
> the end of the tablespace test would mostly prevent that, but that can't help
> in the event of a mid-test crash.

Yeah, I really don't think that we need to worry about multi-user
scenarios with pg_regress like that though.

> I'm not sure we should support installcheck against a server running as a
> different user. If we should support it, then I'd probably look at letting
> the caller pass in a server-writable directory. That directory would house
> the tablespace instead of outputdir doing so.

But, then, we would be back to the pre-13 position where we'd need to
have something external to pg_regress in charge of cleaning up and
creating the tablespace path, no? That's basically what we want to
avoid with the Makefile rules. I can get that it could be interesting
to be able to pass down a custom path for the test tablespace, but do
we really have a need for that?

It took some time for the CF bot to run the patch of this thread, but
from what I can see the tests are passing on Windows under Cirrus CI:
http://commitfest.cputube.org/michael-paquier.html

So it looks like this could be a different answer.
--
Michael

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2021-04-12 07:23:20 Re: pgsql: Silence some Coverity warnings and improve code consistency.
Previous Message Michael Paquier 2021-04-12 04:57:39 pgsql: Move log_autovacuum_min_duration into its correct sections

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-04-12 05:28:37 Re: [PATCH] force_parallel_mode and GUC categories
Previous Message Michael Paquier 2021-04-12 05:07:30 Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)