In previous releases, you needed to have CREATEROLE in order to be able to perform user management functions. In master, you still need CREATEROLE, and you also need ADMIN OPTION on the role. In this scenario, only t1 meets those requirements with respect to t3, so only t1 can manage t3. t2 can SET ROLE to t3 and grant membership in t3, but it can't set role properties on t3 or change t3's password or things like that, because the ability to make user management changes is controlled by CREATEROLE.
ok.
The patch is only intended to change behavior in the case where you possess both CREATEROLE and also ADMIN OPTION on the target role (but not SUPERUSER). In that scenario, it intends to change whether you can give or remove the CREATEDB, REPLICATION, and BYPASSRLS properties from a user.
right, Neha/I have tested with different scenarios using createdb/replication/bypassrls and other
privileges properties on the role. also checked pg_dumpall/pg_basebackup and everything looks fine.
