There are two ways in which access control for replication connections is separate:
- replication pseudo-database in pg_hba.conf - replication role attribute If someone has a restrictive setup for replication and pg_basebackup, and then pg_rewind enters, they will have to - add a line to pg_hba.conf to allow non-replication access - connect as superuser The first is an inconvenience, although it might be useful for this and other reasons to have a variant of "all" includes "replication". The second, however, is a problem, because you have to change from a restricted, quasi-ready-only user to full superuser access. One way to address that might be if we added backend functions that are variants of pg_ls_dir() and pg_stat_file() that are accessible only with the replication attribute. Or we allow calling pg_ls_dir() and pg_stat_file() with relative paths with the replication attribute. (While we're at it, add a recursive variant of pg_ls_dir().) Or some variant of that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
