From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup for streaming base backups |
Date: | 2011-01-17 13:54:50 |
Message-ID: | AANLkTikXd3cCYmYdhCd3oZRcB_DcZ-KfMeW70djyR=4b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 17, 2011 at 14:43, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Mon, Jan 17, 2011 at 9:43 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> Probably yes, for consistency. I have been thinking for a while,
>>> however, that it would be very good if the tools also supported a
>>> conninfo string, so you don't have to invent a new option for every new
>>> connection option. psql already supports that.
>>
>> libpq has an option to expand a connection string if it's passed in
>> the database name, it seems. The problem is that this is done on the
>> dbname parameter - won't work in pg_dump for example, without special
>> treatment, since the db name is used in the client there.
>
> If conninfo is specified, you can just append the "dbname=replication"
> into it and pass it to libpq as dbname. I don't think that supporting
> conninfo is difficult.
Yeah, it's easy enough for pg_basebackup. But not for example for
pg_dump. (I meant for being able to use it more or less with zero
modification to the current code - it can certainly be adapted to be
able to deal with it)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-01-17 13:55:35 | Re: pg_basebackup for streaming base backups |
Previous Message | Magnus Hagander | 2011-01-17 13:50:16 | Re: pg_basebackup for streaming base backups |