Re: [PATCH] Make pg_basebackup configure and start standby [Review] - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Date
Msg-id 506D681D.50002@cybertec.at
Whole thread Raw
In response to Re: [PATCH] Make pg_basebackup configure and start standby [Review]  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: [PATCH] Make pg_basebackup configure and start standby [Review]  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
2012-10-04 06:47 keltezéssel, Boszormenyi Zoltan írta:
> 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.

Did you think about something like the attached code?

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/


Attachment

pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Next
From: Amit Kapila
Date:
Subject: Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation