On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers