First try with role reset

[atanner27]

After pgcat runs a query on a server connection, it runs discard all on that connection to prevent any session state from leaking to other queries and breaking them. This will clear the implicitly set roles.

This PR proposes issuing a second query that will RESET the role post discard.

There may be better options to do this without an additional query and roundtrip.

Sql example:
postgres=> \conninfo
postgres=> SELECT SESSION_USER, CURRENT_USER;
session_user | current_user
--------------+--------------
migrator | migrations
(1 row)

postgres=> DISCARD ALL;
DISCARD ALL
postgres=> SELECT SESSION_USER, CURRENT_USER;
session_user | current_user
--------------+--------------
migrator | migrator
(1 row)

postgres=> RESET ROLE;
RESET
postgres=> SELECT SESSION_USER, CURRENT_USER;
session_user | current_user
--------------+--------------
migrator | migrations
(1 row)

[dat2]

can we ALTER ROLE sharding_user ROLE TO <new role> to simulate the same error we saw in production?

[levkk]

Curious about the error, if you're willing to share. I'm not too familiar with RESET USER.

[dat2]

@levkk we had 2 users in the DB, lets call them A and B.

We had run ALTER ROLE A SET ROLE B, which has the effect of running SET ROLE B after you open a connection with username A. We had configured pgbouncer and pgcat to both connect with username A.

When we run create table on pgbouncer, it was owned by B due to this config.

When we run create table on pgcat, a previous query had run DISCARD ALL in the pgcat server connection, and then the table was owned by A. We found that we could run RESET ROLE to fix it back to SET ROLE b after a DISCARD ALL was run.

Our permissions were all configured with assuming B owns the tables, so when we started creating tables with A as the owner after switching to pgcat, we had some errors.

[levkk]

Thank you sir!