On Monday, July 11, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> bossartn@amazon.com <javascript:;> writes:
> > It is possible to modify the "role" setting in setconfig in the
> > pg_db_role_setting table such that it points to a nonexistent role. When
> > this is the case, restoring the output of pg_dumpall will fail due to the
> > missing role.
>
> > Steps to reproduce:
>
> > 1. As superuser, execute "create role foo with login password 'test'"
> > 2. As foo, execute "alter role foo set role = 'foo'"
> > 3. As superuser, execute "alter role foo rename to bar"
> > a. At this point, the setconfig entry in pg_db_role_setting for
> > 'bar' will contain '{role=foo}', which no longer exists
> > 4. Execute pg_upgrade with the recommended steps in
> > https://www.postgresql.org/docs/current/static/pgupgrade.html
>
> > During pg_upgrade (more specifically, during the restore of the output
> from
> > pg_dumpall), the "ALTER ROLE "bar" SET "role" TO 'foo'" command generated
> > will fail with "ERROR: role "foo" does not exist".
>
> This does not seem like particularly a bug to me. Once you rename the
> role, the ALTER ROLE SET setting is broken already, and it's on your head
> to fix that, not pg_upgrade's. (Or in other words, promising that
> pg_upgrade will succeed in already-malfunctioning installations seems
> to me like a slope we'd better not start down.)
>
>
I'm at a loss to understand what this does when it isn't broken. Assuming
valid grants does the user become the assigned role upon session startup?
Is the behavior even defined in the docs or is this, as suspected below,
and malfunctioning implementation detail?
I am kind of wondering why we allow that parameter to be set in ALTER
> ROLE/DATABASE SET at all, though; especially by unprivileged users.
> Is this example based on a real use-case, and if so what is it?
>
See also:
https://www.postgresql.org/message-id/20150212193420.2590.49423@wrigleys.postgresql.org
Upon further reflection we require custom variables to be namespaced.
There is not, to my knowledge, a documented guc variable named "role".
Something seems off here, but I cannot put my finger on it, even if the
error in question is one we cannot reasonably avoid.
David J.