SR slaves and .pgpass
in [PgSql]
|
Prev: [HACKERS] ps display "waiting for max_standby_delay"
Next: : CRC32 is limiting at COPY/CTAS/INSERT... SELECT + speeding it up
From: Tom Lane on 8 Jun 2010 00:13 Fujii Masao <masao.fujii(a)gmail.com> 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 in 9.1, no? I think a cheap-and-cheerful solution is about right for the moment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 7 Jun 2010 23:01 Fujii Masao <masao.fujii(a)gmail.com> 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 looking at it from the perspective of somebody who knows exactly how the code works. What Andrew tried is exactly what 95% of other people would try. There doesn't seem to me to be any very good argument against making it work for them. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 8 Jun 2010 22:15 On Tue, Jun 8, 2010 at 1:13 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Fujii Masao <masao.fujii(a)gmail.com> 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 of work into hacking .pgpass > processing for this. �The whole business of replication authorization > is likely to get revisited in 9.1, no? �I think a cheap-and-cheerful > solution is about right for the moment. Fair enough. My proposal patch might be too large to apply at this point. >> - snprintf(conninfo_repl, sizeof(conninfo_repl), "%s replication=true", conninfo); >> + snprintf(conninfo_repl, sizeof(conninfo_repl), "%s database=replication replication=true", conninfo); 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. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 8 Jun 2010 23:52 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 way "localhost" is used. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 9 Jun 2010 01:24
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan <andrew(a)dunslane.net> 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 Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center |