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: Fujii Masao on 7 Jun 2010 02:13 On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan <andrew(a)dunslane.net> 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, > 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. What about: diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 5c0d9ab..458a4e2 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -819,7 +819,9 @@ host replication foo 192.168.1.100/32 md5 <para> The host name and port number of the primary, connection user name, and password are specified in the <filename>recovery.conf</> file or - the corresponding environment variable on the standby. + in a separate <filename>~/.pgpass</> on the standby (In the latter case, + <literal>database</> field in a <filename>~/.pgpass</> file must be + <literal>*</>). For example, if the primary is running on host IP <literal>192.168.1.50</>, port <literal>5432</literal>, the superuser's name for replication is <literal>foo</>, and the password is <literal>foopass</>, the administrator diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml index 439db3f..cc351f8 100644 --- a/doc/src/sgml/recovery-config.sgml +++ b/doc/src/sgml/recovery-config.sgml @@ -268,9 +268,11 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows primary (see <xref linkend="streaming-replication-authentication">). A password needs to be provided too, if the primary demands password - authentication. (The password can be provided either in + authentication. The password can be provided either in the <varname>primary_conninfo</varname> string or in a separate - <filename>~/.pgpass</> file on the standby server.) + <filename>~/.pgpass</> file on the standby server (in the latter case, + <literal>database</> field in a <filename>~/.pgpass</> file must be + <literal>*</>). Do not specify a database name in the <varname>primary_conninfo</varname> string. </para> 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: Tom Lane on 7 Jun 2010 11:42 Fujii Masao <masao.fujii(a)gmail.com> writes: > On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan <andrew(a)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 -- 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 7 Jun 2010 12:08 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", conninfo); > > I don't think it's unlikely that someone would try to enter a > replication-specific password into ~/.pgpass. > > > +1. It's highly likely - that's how we got here in the first place. It seems to me like a perfectly reasonable thing to do. 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 7 Jun 2010 22:52 On Tue, Jun 8, 2010 at 12:42 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Fujii Masao <masao.fujii(a)gmail.com> writes: >> On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan <andrew(a)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); What if the real database named "replication" exists? How can we specify the password only for replication purpose in that case? BTW, to distinguish the replication connection from the connection to the real database named "replication", I proposed changing the ..pgpass code so that it accepts the keyword only for replication, like pg_hba.conf. But it was rejected, and as the result of the discussion, we had consensus to not change the code. http://archives.postgresql.org/pgsql-hackers/2010-01/msg00400.php > I don't think it's unlikely that someone would try to enter a > replication-specific password into ~/.pgpass. Agreed. 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? 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: Fujii Masao on 7 Jun 2010 23:58
On Tue, Jun 8, 2010 at 12:01 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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. Hmm.. is it worth going back to my proposal? 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 |