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-13 07:26:46
Message-ID: YHVHtjRNUGy13VpO@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Mon, Apr 12, 2021 at 10:36:10PM -0700, Noah Misch wrote:
> Christoph Berg's first message on this thread reported doing that. If
> supporting server_user!=pg_regress_user is unwarranted and Christoph Berg
> should stop, then already-committed code suffices.

Not sure that we have ever claimed that. It is unfortunate that this
has broken a case that used to work, perhaps accidentally. At the
same time, Christoph has a workaround for the Debian suite, so it does
not seem like there is anything to do now, anyway.

> The race that commit 6c788d9 fixed is not inherent to Makefile rules. For
> example, you could have instead caused test.sh to issue 'make
> installcheck-parallel TABLESPACEDIR="$outputdir"/testtablespace' and have the
> makefiles consult $(TABLESPACEDIR) rather than hard-code ./testtablespace.
> (That said, I like how 6c788d9 consolidated Windows and non-Windows paths.)

FWIW, I don't really want to split again this code path across
platforms. Better to have one to rule them all.

> I don't know. I never considered server_user!=pg_regress_user before this
> thread, and I don't plan to use it myself. Your latest patch originated to
> make that case work, and my last message was reporting that the patch works
> for a rather-narrow interpretation of server_user!=pg_regress_user, failing on
> variations thereof. That might be fine.

Okay. So.. As I am not sure if there is anything that needs to be
acted on here for the moment, I would just close the case. If there
are more voices in favor of the SQL function using mkdir(), I would
not object to use that, as that looks to work for all the cases where
pg_regress is used.
--
Michael

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2021-04-13 16:17:39 pgsql: Avoid improbable PANIC during heap_update.
Previous Message Noah Misch 2021-04-13 05:36:10 Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-04-13 07:34:23 Re: [PATCH] force_parallel_mode and GUC categories
Previous Message Fujii Masao 2021-04-13 07:17:12 Re: TRUNCATE on foreign table