Re: DROP OWNED BY fails to clean out pg_init_privs grants

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: DROP OWNED BY fails to clean out pg_init_privs grants
Date: 2024-04-21 21:08:08
Message-ID: 2857513.1713733688@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 6 Apr 2024, at 01:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-04-21 21:49:47 Re: fix tablespace handling in pg_combinebackup
Previous Message Tomas Vondra 2024-04-21 19:34:47 Re: createdb compares strategy as case-sensitive