bossartn@amazon.com 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 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?
regards, tom lane