[pgpool-hackers: 129] Re: Enabling -D switch of pgpool by default

[alex]

On 9/12/12 3:06 PM, Gurjeet Singh wrote:
> On Wed, Sep 12, 2012 at 5:45 PM, Tatsuo Ishii <ishii at postgresql.org 
> <mailto:ishii at postgresql.org>> wrote:
>
>     > So far I haven't heard of any damaging or detrimental effects of
>     -D option.
>     > The only effect and overhead that I can verify is that with -D
>     option
>     > pgpool will connect to every backend_hostname to verify whether the
>     > database backend is reachable. This may cause some slowdown in
>     initial
>     > pgpool startup, but the upside is that the backend_status value
>     reflects
>     > the true status of a backend.
>
>     Really? At least Alex and I are not sure if it's a really good idea,
>     while no one is with your idea. Also I would like to hear from Devrim
>     since he is the mainter of init scripts.
>
>
> Well, the only argument I have heard is that once added to init 
> script, it will be difficult to disable its effect, like one could do 
> by using $OPTS env variable. What I consider 'damaging or detrimental' 
> is if someone said "That'll cause wrong results in certain mode of 
> operation (say replication)" or "this will cause a crash" or "this 
> will make some backend nodes unavailable via pgpool". If -D option 
> does not cause any unintended effects, I think it is safe for me to 
> use. I hope you get my point.

Safe for you to use doesn't justify changing the default behavior, 
though.  It just makes it safe for you to use.

Consider the scenario in which someone disables a backend intentionally 
to do some kind of work on it.  In that case the user would want the 
backend to remain disabled until the work is done and he/she manually 
re-enables the backend.  The current default acts that way and users 
would reasonably expect v3.3 and above to keep the same default behavior.

Again, /etc/sysconfig/pgpool allows you to do whatever you want --and 
shouldn't get overwritten by rpm updates or the spec file needs fixing-- 
without changing expected behavior for everyone else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20120912/f54e6a9f/attachment.html>