Re: DROP OWNED BY fails to clean out pg_init_privs grants - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP OWNED BY fails to clean out pg_init_privs grants
Date
Msg-id 2857513.1713733688@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP OWNED BY fails to clean out pg_init_privs grants  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: DROP OWNED BY fails to clean out pg_init_privs grants
Re: DROP OWNED BY fails to clean out pg_init_privs grants
List pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 6 Apr 2024, at 01:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (So now I'm wondering why *only* copperhead has shown this so far.
>> Are our other cross-version-upgrade testing animals AWOL?)

> Clicking around searching for Xversion animals I didn't spot any, but without
> access to the database it's nontrivial to know which animal does what.

I believe I see why this is (or isn't) happening.  The animals
currently running xversion tests are copperhead, crake, drongo,
and fairywren.  copperhead is using the makefiles while the others
are using meson.  And I find this in
src/test/modules/test_pg_dump/meson.build (from 3f0e786cc):

    # doesn't delete its user
    'runningcheck': false,

So the meson animals are not running the test that sets up the
problematic data.

I think we should remove the above, since (a) the reason to have
it is gone, and (b) it seems really bad that the set of tests
run by meson is different from that run by the makefiles.

However, once we do that, those other three animals will presumably go
red, greatly complicating detection of any Windows-specific problems.
So I'm inclined to not do it till just before we intend to commit
a fix for the underlying problem.  (Enough before that we can confirm
that they do go red.)

Speaking of which ...

>> I doubt this is something we'll have fixed by Monday, so I will
>> go add an open item for it.

> +1. Having opened the can of worms I'll have a look at it next week.

... were you going to look at it?  I can take a whack if it's
too far down your priority list.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: createdb compares strategy as case-sensitive
Next
From: Thomas Munro
Date:
Subject: Re: fix tablespace handling in pg_combinebackup