[pgpool-hackers: 4111] Re: What to do with ParamterStatus?

[Tatsuo Ishii]

>>>> Currently Pgpool-II only processes ParameterStatus messages at the
>>>> connection starting up phase. In the phase all ParameterStatus
>>>> messages from the primary node are forwarded to frontend. If value for
>>>> a ParameterStatus is differ among backends, only the value of primary
>>>> node is forwarded and the value of standby nodes are ignored.  In this
>>>> case it is logged that the message lenth (thus values) are differ
>>>> (except is_hot_standby, which is always differ among primary and
>>>> standby). So far so good.
>>>> 
>>>> Question is, in the case ParameterStatus message arrives after
>>>> establishing the session. This could happen in certain cases. For
>>>> example, postgresql.conf is changed and reloaded. The other case is,
>>>> SET command is rolled back. Currently Pgpool-II ignores
>>>> ParameterStatus messages in these cases.
>>>> 
>>>> I think this is not good because frontend never knows the value of
>>>> parameters have been changed. So what should we do?
>>>> 
>>>> 1) Every time ParameterStatus message is received, forward it to
>>>> frontend. Even the value for standby servers are forwarded. This may
>>>> result in receiving multiple ParameterStatus for frontend if user
>>>> changes postgresql.conf and reloads it on each server.
>>>> 
>>>> 2) Process ParameterStatus only when the message is received from the
>>>> primary server.
>>>> 
>>>> 3) Other.
>>>> 
>>>> I think #2 is reasonable because it is consistent with the process
>>>> done at the starting up.
>>> 
>>> After thinking a little bit harder, it seems #1 is more reasonable
>>> than #2. The event (ParameterStatus is generated) is mostly happening
>>> when admin changes a parameter and reloads config file.  This will be
>>> done at each server of the cluster one by one. If pgpool only picks up
>>> the ParameterStatus at primary server, the admin might be confused
>>> when changing/reloading config file at standby servers. So I guess #1
>>> is less confusing than #2 for admins.
>> 
>> And this is the patch for #2.
> 
> Slightly enhanced patch in message format.

Pushed to master branch.

Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp