[pgpool-hackers: 4126] 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.

Pushed to all supported branches.

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