> On 1 Dec 2023, at 12:37, Heikki Linnakangas <hlinn...@iki.fi> wrote: > > On 01/12/2023 13:22, Daniel Gustafsson wrote: >>> On 8 Nov 2023, at 13:32, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: >>> I suppose you're just thinking of using PQexec() or whatever, run one >>> query with sufficient ORDER BY, save the result, and at the end of the >>> test run just run the same query and compare that they are cell-by-cell >>> identical? This sounds a lot simpler than the patch you posted. >> I found some spare cycles for this and came up with the attached. The idea >> was >> to keep it in-line with how pg_regress already today manipulate and traverse >> _stringlists for various things. With the addition of the 0001 patch to >> clean >> up global objects left in test_pg_dump it passes check-world. > > Do we want to impose this policy to all extensions too?
I don't think it would be bad, and as of today the policy holds for all of check-world apart from this one test module. >> + /* >> + * Store the global objects before the test starts such that we can >> check >> + * for any objects left behind after the tests finish. >> + */ >> + query_to_stringlist("postgres", >> + "(SELECT rolname AS obj FROM >> pg_catalog.pg_roles ORDER BY 1) " >> + "UNION ALL " >> + "(SELECT spcname AS obj FROM >> pg_catalog.pg_tablespace ORDER BY 1) " >> + "UNION ALL " >> + "(SELECT subname AS obj FROM >> pg_catalog.pg_subscription ORDER BY 1)", >> + &globals_before); >> + > > Strictly speaking, the order of this query isn't guaranteed to be stable, > although in practice it probably is. Of course, will fix. I originally had three separate query_to_stringlist calls and had a brainfade when combining. It seemed like pointless use of cycles when we can get everything in one connection. > Is it OK to leave behind extra databases? The test suite for pg_upgrade can make use of left behind databases to seed the old cluster, so I think that's allowed by design. -- Daniel Gustafsson