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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: 2024-03-27 13:42:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers

> On 25 Mar 2024, at 19:48, Andres Freund <andres(at)anarazel(dot)de> wrote:

> I don't think it's that, but that the freebsd task tests the installcheck
> equivalent in meson. I haven't checked what your patch is doing, but perhaps
> the issue is that it's seeing global objects concurrently created by another
> test?

Sorry, I had a look when Peter replied a while back but forgot to update this
thread. The reason for the failure is that when running multiple pg_regress in
parallel against a single instance it is impossible to avoid global object
pollution from other tests concurrently executing. Since pg_regress has no
idea about the contents of the tests it also cannot apply any smarts in
filtering out such objects. The CI failures comes from the contrib tests which
run in parallel.

The only option is to make the check opt-in via a command-line parameter for
use it in the main regress tests, and not use it for the contrib tests. The
attached v7 does that and passes CI, but I wonder if it's worth it all with
that restriction?

The 0001 cleanup patch is still relevant (and was found by using this feature)
though but that might be all for this thread.

Daniel Gustafsson

Attachment Content-Type Size
v7-0002-pg_regress-Detect-global-objects-left-over-after-.patch application/octet-stream 6.3 KB
v7-0001-Drop-global-objects-after-completed-test.patch application/octet-stream 1.7 KB

In response to


Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2024-03-27 14:33:28 Re: pgsql: Track last_inactive_time in pg_replication_slots.
Previous Message David Rowley 2024-03-27 11:14:36 pgsql: Fix unstable aggregate regression test

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-03-27 14:10:50 Re: Streaming I/O, vectored I/O (WIP)
Previous Message Bertrand Drouvot 2024-03-27 13:24:52 Re: Introduce XID age and inactive timeout based replication slot invalidation