Re: SR slaves and .pgpass - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SR slaves and .pgpass
Date
Msg-id 16728.1275925325@sss.pgh.pa.us
Whole thread Raw
In response to Re: SR slaves and .pgpass  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: SR slaves and .pgpass  (Andrew Dunstan <andrew@dunslane.net>)
Re: SR slaves and .pgpass  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> writes:
> On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> I tried this with a database name of "replication" in the .pgpass file,
>> which matches what we need to use in pg_hba.conf, but it failed miserably,
>> and only worked when I used a wildcard for the database name in the .pgpass
>> file.
>> 
>> If this is expected it needs to be documented more clearly; if not, it's a
>> bug.

> Yep, this is expected, so we need to improve the doc.

Why don't we improve the code, instead?  In particular make
libpqrcv_connect() do

-    snprintf(conninfo_repl, sizeof(conninfo_repl), "%s replication=true", conninfo);
+    snprintf(conninfo_repl, sizeof(conninfo_repl), "%s database=replication replication=true", conninfo);

I don't think it's unlikely that someone would try to enter a
replication-specific password into ~/.pgpass.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [BUGS] Invalid YAML output from EXPLAIN
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add current WAL end (as seen by walsender, ie, GetWriteRecPtr()