Re: [HACKERS] SR slaves and .pgpass

2010-06-14 Thread Magnus Hagander
On Mon, Jun 14, 2010 at 04:56, Fujii Masao wrote: > On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas > wrote: >> On 09/06/10 08:24, Fujii Masao wrote: >>> >>> On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan >>>  wrote: There is precedent for .pgpass being a bit ambiguous. See the way

Re: [HACKERS] SR slaves and .pgpass

2010-06-13 Thread Fujii Masao
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas wrote: > On 09/06/10 08:24, Fujii Masao wrote: >> >> On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan >>  wrote: >>> >>> There is precedent for .pgpass being a bit ambiguous. See the way >>> "localhost" is used. >> >> OK. The attached patch allows

Re: [HACKERS] SR slaves and .pgpass

2010-06-11 Thread Fujii Masao
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas wrote: > On 09/06/10 08:24, Fujii Masao wrote: >> >> On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan >>  wrote: >>> >>> There is precedent for .pgpass being a bit ambiguous. See the way >>> "localhost" is used. >> >> OK. The attached patch allows

Re: [HACKERS] SR slaves and .pgpass

2010-06-11 Thread Heikki Linnakangas
On 09/06/10 08:24, Fujii Masao wrote: On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan wrote: There is precedent for .pgpass being a bit ambiguous. See the way "localhost" is used. OK. The attached patch allows us to use "replication" in the database field of the .pgpass file, for the replicat

Re: [HACKERS] SR slaves and .pgpass

2010-06-08 Thread Fujii Masao
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan wrote: > There is precedent for .pgpass being a bit ambiguous. See the way > "localhost" is used. OK. The attached patch allows us to use "replication" in the database field of the .pgpass file, for the replication connection. Regards, -- Fujii M

Re: [HACKERS] SR slaves and .pgpass

2010-06-08 Thread Andrew Dunstan
Fujii Masao wrote: Tom's proposal is very small, but we cannot distinguish the password for replication purpose from that for the real database named "replication". Is this OK? I can live with this as far as it's documented. There is precedent for .pgpass being a bit ambiguous. See the wa

Re: [HACKERS] SR slaves and .pgpass

2010-06-08 Thread Fujii Masao
On Tue, Jun 8, 2010 at 1:13 PM, Tom Lane wrote: > Fujii Masao writes: >> Hmm.. is it worth going back to my proposal? > > I don't recall exactly what proposal you might be referring to, but http://archives.postgresql.org/pgsql-hackers/2010-01/msg00400.php > I'm hesitant to put any large amount

Re: [HACKERS] SR slaves and .pgpass

2010-06-07 Thread Tom Lane
Fujii Masao writes: > Hmm.. is it worth going back to my proposal? I don't recall exactly what proposal you might be referring to, but I'm hesitant to put any large amount of work into hacking .pgpass processing for this. The whole business of replication authorization is likely to get revisited

Re: [HACKERS] SR slaves and .pgpass

2010-06-07 Thread Fujii Masao
On Tue, Jun 8, 2010 at 12:01 PM, Tom Lane wrote: > Fujii Masao writes: >> But I think that we don't need to specify other than the wildcard >> in the database field of .pgpass to use the replication-specific >> password if the replication-specific user is supplied in .pgpass. >> So the current co

Re: [HACKERS] SR slaves and .pgpass

2010-06-07 Thread Tom Lane
Fujii Masao writes: > But I think that we don't need to specify other than the wildcard > in the database field of .pgpass to use the replication-specific > password if the replication-specific user is supplied in .pgpass. > So the current code is enough for me. Am I missing something? You're loo

Re: [HACKERS] SR slaves and .pgpass

2010-06-07 Thread Fujii Masao
On Tue, Jun 8, 2010 at 12:42 AM, Tom Lane wrote: > Fujii Masao writes: >> On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan 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

Re: [HACKERS] SR slaves and .pgpass

2010-06-07 Thread Andrew Dunstan
Tom Lane wrote: 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", connin

Re: [HACKERS] SR slaves and .pgpass

2010-06-07 Thread Tom Lane
Fujii Masao writes: > On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan 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 t

Re: [HACKERS] SR slaves and .pgpass

2010-06-06 Thread Fujii Masao
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan wrote: > > The docs state, w.r.t. $subject: > >   The password can be provided either in the primary_conninfo string >   or in a separate ~/.pgpass file on the standby server. > > I tried this with a database name of "replication" in the .pgpass file,