Re: pgsql: Remove reset of testtablespace from pg_regress on Windows

On 7/9/20 9:02 PM, Michael Paquier wrote:
> On Thu, Jul 09, 2020 at 07:28:02PM -0400, Andrew Dunstan wrote:
>> This patch has carefully removed the ability to run the regression tests
>> as a Windows administrative user, as I just discovered. This was the
>> whole point of commit ce5d3424d6.
>>
>> I assume the testing referred to above was not as a privileged user. I
>> think this should be reverted.
> Thanks Andrew.  This was discussed on the original thread and what I
> wanted to do a rvert if you look at its newest history:
> https://www.postgresql.org/message-id/20200623014036.GF50978@paquier.xyz
> And then, the thread just stalled..  So I was not sure if something
> was actually wanted or not.
>
> Now, I don't think that just a simple revert is the best answer we can
> provide.  Just look at this comment in pg_regress.c that does not give
> a hint that we actually should not remove this code:
> -    * On Windows only, clean out the test tablespace dir, or create it if it
> -    * doesn't exist.  On other platforms we expect the Makefile to take care
> -    * of that.  (We don't migrate that functionality in here because it'd be
> -    * harder to cope with platform-specific issues such as SELinux.)
> -    *
> -    * XXX it would be better if pg_regress.c had nothing at all to do with
> -    * testtablespace, and this were handled by a .BAT file or similar on
> -    * Windows.  See pgsql-hackers discussion of 2008-01-18.
>
> So instead I would like to propose the attached, reworking this
> comment as follows (basically a revert, except for this comment):
> +   /*
> +    * On Windows only, clean out the test tablespace dir, or create it if it
> +    * doesn't exist so as it is possible to run the regression tests as a
> +    * Windows administrative user account with the restricted token obtained
> +    * when starting pg_regress.  On other platforms we expect the Makefile
> +    * to take care of that.
> +    */
>
> What do you think?



I certainly agree we should document more clearly why it's there, to
help forestall anyone else who comes along and thinks it would just be
neater to remove it. so +1.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services