Re: pg_init_privs corruption.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kirill Reshke <reshke(at)double(dot)cloud>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_init_privs corruption.
Date: 2023-02-17 18:43:01
Message-ID: 2715293.1676659381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kirill Reshke <reshke(at)double(dot)cloud> writes:
> As you can see, after drop role there is invalid records in pg_init_privs
> system relation. After this, pg_dump generate sql statements, some of which
> are based on content of pg_init_privs, resulting in invalid dump.

Ugh.

> PFA fix.

I don't think this is anywhere near usable as-is, because it only
accounts for pg_init_privs entries in the current database. We need
to handle these records in the DROP OWNED BY mechanism instead, and
also ensure there are shared-dependency entries for them so that the
role can't be dropped until the entries are gone in all DBs. The real
problem may be less that DROP is doing the wrong thing, and more that
creation of the pg_init_privs entries neglects to record a dependency.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2023-02-17 19:00:21 Re: The output sql generated by pg_dump for a create function refers to a modified table name
Previous Message Justin Pryzby 2023-02-17 18:41:40 Re: Move defaults toward ICU in 16?