Re: 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This strikes me as a completely bad idea.  We need get no farther than
> the point that it assumes nobody can have a database named "replication"

Though I might misunderstand your point. My proposal would force the users
who have a database named "replication" to change their .pgpass file and
enclose the "replication" database field in double quote when they upgrade
the Postgres to v8.5. For example;

192.168.1.50:5432:"replication":foo:foopass

The same problem also exists in pg_hba.conf. It's because I introduced
new keyword "replication" in pg_hba.conf to authenticate the standby
server. This restriction is not acceptable? If so, I'd need to consider
an authentication configuration for replication again: introduce new
configuration file? just change the keyword name to "unpopular" one?...

> (although I notice the patch also appears to assume that libpq knows
> internally that the connection is for replication --- I thought we were
> going to avoid libpq changes for SR?)

Yes, but I changed the libpq just a bit; if the conninfo string including
"replication=1" is given to PQconnectdb(), the libpq determines that this
connection is for replication, and puts the replication-request in a startup
packet. This is for a backend to switch to walsender mode when the startup
packet arrives. Otherwise, we would have to authenticate such backend twice
on different context, i.e., a normal backend and walsender. So the settings
for each context would be required in pg_hba.conf. This is odd, I think.

> I don't see any real strong reason why a .pgpass entry for this purpose
> couldn't depend on having "*" in the database field.

Oh, you are right. Since a role cannot use a different password per database,
"*" in the database field seems to be enough.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center