Re: Preventing non-superusers from altering session authorization

I've discovered an issue with this approach. Let's say you have some
session open that is connected as a superuser and you run the following commands:

  - CREATE ROLE r1 LOGIN SUPERUSER;
  - CREATE ROLE r2;
  - CREATE ROLE r3;

Then you open another session connected with user r1 and run the
following commands:

  - SET SESSION AUTHROIZATION r2;
  - BEGIN;
  - SET SESSION AUTHORIZATION r3;

Then in your original session run:

  - ALTER ROLE r1 NOSUPERUSER;

Finally in the r1 session run:

  - CREATE TABLE t ();

Postgres will then panic with the following logs:

2023-07-08 16:33:27.787 EDT [157141] ERROR:  permission denied for schema public at character 14
2023-07-08 16:33:27.787 EDT [157141] STATEMENT:  CREATE TABLE t ();
2023-07-08 16:33:27.787 EDT [157141] ERROR:  permission denied to set session authorization
2023-07-08 16:33:27.787 EDT [157141] WARNING:  AbortTransaction while in ABORT state
2023-07-08 16:33:27.787 EDT [157141] ERROR:  permission denied to set session authorization
2023-07-08 16:33:27.787 EDT [157141] WARNING:  AbortTransaction while in ABORT state
2023-07-08 16:33:27.787 EDT [157141] ERROR:  permission denied to set session authorization
2023-07-08 16:33:27.787 EDT [157141] WARNING:  AbortTransaction while in ABORT state
2023-07-08 16:33:27.787 EDT [157141] ERROR:  permission denied to set session authorization
2023-07-08 16:33:27.787 EDT [157141] PANIC:  ERRORDATA_STACK_SIZE exceeded
2023-07-08 16:33:27.882 EDT [156878] LOG:  server process (PID 157141) was terminated by signal 6: Aborted
2023-07-08 16:33:27.882 EDT [156878] DETAIL:  Failed process was running: CREATE TABLE t ();

I think the issue here is that if a session loses the ability to set
their session authorization in the middle of a transaction, then
rolling back the transaction may fail and cause the server to panic.
That's probably what the deleted comment mean when it said:

> * It's OK because the check does not require catalog access and can't