Re: pgsql: Clean up role created in new subscription test. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql: Clean up role created in new subscription test.
Date
Msg-id 267900.1680201870@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Clean up role created in new subscription test.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Clean up role created in new subscription test.  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Mar 30, 2023 at 1:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This oversight broke repeated runs of "make installcheck".

> GAAAAH. You would think that I would have learned better by now, but
> evidently not. Is there some way we can add an automated guard against
> this?

Hm.  We could add a final test step that prints out all still-existing
roles, but the trick is to have it not fail in a legitimate installcheck
context (ie, when there are indeed some pre-existing roles).

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.

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 would then be enforced against all pg_regress suites not just
the main one, but perhaps that's good.

Likewise for tablespaces, subscriptions, and other globally-visible
objects, of course.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Transparent column encryption
Next
From: Andres Freund
Date:
Subject: Re: Thoughts on using Text::Template for our autogenerated code?