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

Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parameter_status_v2.patch
Type: text/x-patch
Size: 2066 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-hackers/attachments/20220118/abe5aec0/attachment.bin>