On Mon, Jun 14, 2010 at 04:56, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@dunslane.net
wrote:
There is
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@dunslane.net
wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
localhost is
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@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,
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@dunslane.net
wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
localhost is
On Tue, Jun 8, 2010 at 1:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@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
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
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan and...@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.
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@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
Fujii Masao masao.fu...@gmail.com writes:
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@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
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,
On Tue, Jun 8, 2010 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@dunslane.net wrote:
I tried this with a database name of replication in the .pgpass file,
which matches what we need to use in
Fujii Masao masao.fu...@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
On Tue, Jun 8, 2010 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@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
Fujii Masao masao.fu...@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
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
15 matches
Mail list logo
