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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Mar 30, 2023 at 1:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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