Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Boszormenyi Zoltan <zb@cybertec.at>
From: Boszormenyi Zoltan <zb@cybertec.at>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Amit Kapila <amit.kapila@huawei.com>, 'Hans-Jürgen Schönig' <hs@cybertec.at>, 'Pg Hackers' <pgsql-hackers@postgresql.org>, Magnus Hagander <magnus@hagander.net>, Fujii Masao <masao.fujii@gmail.com>
Date: 2012-10-04T04:47:09Z
Lists: pgsql-hackers
2012-10-04 05:24 keltezéssel, Peter Eisentraut írta:
> On Wed, 2012-10-03 at 18:15 +0200, Boszormenyi Zoltan wrote:
>> The second generation of this work is now attached and contains a new
>> feature as was discussed and suggested by Magnus Hagander, Fujii Masao
>> and Peter Eisentraut. So libpq has grown a new function:
>>
>> +/* return the connection options used by a live connection */
>> +extern PQconninfoOption *PQconninfo(PGconn *conn);
>>
>> This copies all the connection parameters back from the live PGconn
>> itself
>> so everything that's needed to connect is already validated.
> I don't like that this code maintains a second list of all possible
> libpq connection parameters.
Where does it do that? In PQconninfo() itself? Why is it a problem?
Or to put it bluntly: the same problem is in fillPGconn() too, as it also
has the same set of parameters listed. So there is already code
that you don't like. :-)
How about a static mapping between option names and
offsetof(struct pg_conn, member) values? This way both fillPGconn()
and PQconninfo() can avoid maintaining the list of parameter names.
> The parameters to add to the connection
> string should be driven off the authoritative list in PQconninfoOptions.
So, should I add a second flag to PQconninfoOption to indicate that
certain options should not be used for primary_conninfo?
Thanks and best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make the streaming replication protocol messages architecture-independent.
- add6c3179a4d 9.3.0 cited