Re: pgsql: Clean up role created in new subscription test.

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Clean up role created in new subscription test.
Date: 2023-03-30 19:19:17
Message-ID: 99112997-6732-42C7-989B-06406C911FE2@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

> On 30 Mar 2023, at 20:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Maybe it'd be close enough to expect there to be no roles named
> "regress_xxx". In combination with
> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, that would prevent us
> from accidentally leaving stuff behind, and we could hope that it doesn't
> cause false failures in real installations.

Would that check be always on or only when pg_regress is compiled with
-DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS?

> Another idea could be for pg_regress to enforce that "select count(*)
> from pg_roles" gives the same answer before and after the test run.

That wouldn't prevent the contents of pg_roles to have changed though, so there
is a (slim) false positive risk with that no?

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Geoghegan 2023-03-30 19:27:14 pgsql: Show record information in pg_get_wal_block_info.
Previous Message Alvaro Herrera 2023-03-30 19:08:33 pgsql: Simplify transformJsonAggConstructor() API

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-03-30 19:23:15 Re: Parallel Full Hash Join
Previous Message Aleksander Alekseev 2023-03-30 19:17:07 Re: ResourceOwner refactoring