RDS Postgres - is rds_replication role necessary in steady state?

[ayymart]

Jesse Seldess drafted the following procedure for deploying readyset against an RDS postgres upstream while granting the minimum roles/privileges required:

Recommended: Create a new user for readyset and grant it the following privileges so it can create event triggers and start the replication process on initial connection: grant rds_superuser to <user>; grant connect on database <database> to <user>; grant create on database <database> to <user>;. Also grant the privileges required for the operations you will send through ReadySet. For example, if you’ll just be sending reads to readyset, you’d need: grant select on all tables in schema <schema> to <user>;. If you’ll be sending inserts, deletes, updates, and/or schema changes, you’ll need to change the user permissions for those as well.

Cautious: After starting readyset, revoke rds_superuser status so your readyset user can’t do things like create roles and create databases (see here for a list of what rds_superuser can do) and assign the rds_replication status so your readyset user can continue consuming the replication stream: revoke rds_superuser from <user>; grant rds_replication to <user>;.

However, his observation was that the rds_replication role wasn’t actually necessary to start logical replication upon restarting readyset. We should confirm whether this is the case.

The relevant queries for which we need certain permissions are found in public/replicators/src/postgres_connector/connector.rs.