On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane <tgl@sss.pgh.pa.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