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

From Daniel Gustafsson
Subject Re: DROP OWNED BY fails to clean out pg_init_privs grants
Date
Msg-id 33E80863-5516-45A1-93D1-00F1A166EC7C@yesql.se
Whole thread Raw
In response to Re: DROP OWNED BY fails to clean out pg_init_privs grants  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DROP OWNED BY fails to clean out pg_init_privs grants
List pgsql-hackers
> On 28 Apr 2024, at 20:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> Here's a draft patch that attacks that.  It seems to fix the
>> problem with test_pg_dump: no dangling pg_init_privs grants
>> are left behind.

Reading this I can't find any sharp edges, and I prefer your changes to
recordExtensionInitPriv over the version I had half-baked by the time you had
this finished.  Trying to break it with the testcases I had devised also
failed, so +1.

> Here's a v2 that attempts to add some queries to test_pg_dump.sql
> to provide visual verification that pg_shdepend and pg_init_privs
> are updated correctly during DROP OWNED BY.  It's a little bit
> nasty to look at the ACL column of pg_init_privs, because that text
> involves the bootstrap superuser's name which is site-dependent.
> What I did to try to make the test stable is
>
>  replace(initprivs::text, current_user, 'postgres') AS initprivs

Maybe that part warrants a small comment in the testfile to keep it from
sending future readers into rabbitholes?

> This is of course not bulletproof: with a sufficiently weird
> bootstrap superuser name, we could get false matches to parts
> of "regress_dump_test_role" or to privilege strings.  That
> seems unlikely enough to live with, but I wonder if anybody has
> a better idea.

I think that will be bulletproof enough to keep it working in the buildfarm and
among 99% of hackers.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Possible to get LIMIT in an index access method?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Direct SSL connection and ALPN loose ends