Re: pg_regress cleans up tablespace twice.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_regress cleans up tablespace twice.
Date: 2020-06-23 01:40:36
Message-ID: 20200623014036.GF50978@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 21, 2020 at 10:38:22PM +1200, Thomas Munro wrote:
> On Sun, Jun 21, 2020 at 8:42 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Thanks, and sorry for the trouble. What actually happened back in
>> 2018? I can see c2ff3c68 in the git history of the cfbot code, but it
>> does not give much details.
>
> commit ce5d3424d6411f7a7228fd4463242cb382af3e0c
> Author: Andrew Dunstan <andrew(at)dunslane(dot)net>
> Date: Sat Oct 20 09:02:36 2018 -0400
>
> Lower privilege level of programs calling regression_main
>
> On Windows this mean that the regression tests can now safely and
> successfully run as Administrator, which is useful in situations like
> Appveyor. Elsewhere it's a no-op.
>
> Backpatch to 9.5 - this is harder in earlier branches and not worth the
> trouble.
>
> Discussion:
> https://postgr.es/m/650b0c29-9578-8571-b1d2-550d7f89f307@2ndQuadrant.com

Thanks for the reference. This also means that as much as I'd like to
keep the recreation of testtablespace out of pg_regress for
consistency, 2b2a070 has also broken a case we have claimed to support
since ce5d342.

A bit of digging around I have found this case from a guy of Yandex,
visibly running our regression test suite:
https://help.appveyor.com/discussions/questions/1888-running-tests-with-reduced-privileges

And the conclusion seems like it is not really possible to do that
within appveyor, using a trick with openssh to manipulate privileges
as wanted, as referenced here:
https://github.com/yandex-qatools/postgresql-embedded

At the end of the day, it looks more simple to me to just revert
2b2a070 if we just want to keep your stuff running without extra
workload from your side. Extra opinions are welcome.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-06-23 01:43:47 Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)
Previous Message Thomas Munro 2020-06-23 01:30:39 Move syncscan.c?