|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
|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|