Re: pg_upgrade check for invalid role-specific default config

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Charlie Hornsby <charlie(dot)hornsby(at)hotmail(dot)co(dot)uk>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade check for invalid role-specific default config
Date: 2021-04-12 23:33:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> Another answer is that maybe the processing of the "role" case
> in particular is just broken.

After digging around a bit more, I think that that is indeed the
right answer. Most of the GUC check functions that have
database-state-dependent behavior are programmed to behave specially
when checking a proposed ALTER USER/DATABASE setting; but check_role
and check_session_authorization did not get that memo. I also
noted that check_temp_buffers would throw an error for no very good
reason. There don't look to be any other troublesome cases.
So I ended up with the attached.

It feels a bit unsatisfactory to have these various check functions
know about this explicitly. However, I'm not sure that there's a
good way to centralize it. Only the check function knows whether
the check it's making is immutable or dependent on DB state --- and
in the former case, not throwing an error wouldn't be an improvement.

Anyway, I'm inclined to think that we should not only apply this
but back-patch it. Two complaints is enough to suggest we have
an issue. Plus, I think there is a dump/reload ordering problem
here: as things stand, "alter user joe set role = bob" would work
or not work depending on the order the roles are created in
and/or the order privileges are granted in.

regards, tom lane

Attachment Content-Type Size
fix-alter-user-database-set-role.patch text/x-diff 2.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-04-12 23:35:13 Re: Teaching users how they can get the most out of HOT in Postgres 14
Previous Message Michael Paquier 2021-04-12 23:31:04 Re: psql - add SHOW_ALL_RESULTS option