From: Haribabu Kommi [mailto:kommi.harib...@gmail.com] > while going through the old patch where the GUC_REPORT is implemented, Tom > has commented the logic of sending the signal to all backends to process > the hot standby exit with SIGHUP, if we add the logic of updating the GUC > variable value in SIGHUP, we may need to change all the SIGHUP handler code > paths. It is also possible that there is no need to update the variable > for other processes except backends. > > If we go with adding the new SIGUSR1 type to check and update the GUC varaible > can work for most of the backends and background workers. > > opinions
SIGUSR1 looks reasonable. We can consider it as notifying that the server status has changed. I've fully reviewed 0001-0003 and my comments follow. I'll review 0004-0007. (1) 0001 before issuing the transaction_readonly to find out whether the server is read-write or not is restuctured under a new transaction_readonly -> "SHOW transaction_read_only" restuctured -> restructured (2) 0001 + succesful connection or failure. + successful connection; if it returns <literal>on</literal>, means server succesful -> successful means -> it means (3) 0003 + But for servers version 12 or greater uses the <varname>transaction_read_only</varname> + GUC that is reported by the server upon successful connection. GUC doesn't seem to be a term to be used in the user manual. Instead: uses the value of <varname>transaction_read_only</varname> configuration parameter that is... as in: https://www.postgresql.org/docs/devel/libpq-connect.html client_encoding This sets the client_encoding configuration parameter for this connection. application_name Specifies a value for the application_name configuration parameter. (4) 0003 bool std_strings; /* standard_conforming_strings */ + bool transaction_read_only; /* session_read_only */ Looking at the comment for std_strings, it's better to change the comment to transaction_read_only to represent the backing configuration parameter name. Regards Takayuki Tsunakawa
