On 2018-02-14 11:12:30 +0900, Tatsuo Ishii wrote: > According to the manual, backend sends a parameter status message when > certain configuration variable has been changed and SIGHUP signal is sent. > https://www.postgresql.org/docs/10/static/protocol-flow.html#PROTOCOL-ASYNC > > ParameterStatus messages will be generated whenever the active value > changes for any of the parameters the backend believes the frontend > should know about. Most commonly this occurs in response to a SET > SQL command executed by the frontend, and this case is effectively > synchronous ― but it is also possible for parameter status changes > to occur because the administrator changed a configuration file and > then sent the SIGHUP signal to the server. > > So I connected to PostgreSQL using psql and attached strace to psql. > Then I changed standard_conforming_strings and executed pg_ctl > reload. The PostgreSQL log shows: > > 12073 2018-02-14 11:05:22 JST LOG: received SIGHUP, reloading configuration files > 12073 2018-02-14 11:05:22 JST LOG: parameter "standard_conforming_strings" changed to "off" > 12073 2018-02-14 11:05:22 JST DEBUG: sending signal 1 to process 12158 > > But as far as strace tells, nothing was sent to psql. Is this expected?
It'll only get sent to the client the next time the server processes a query. We can't just at arbitrary points reload the config file or send messages out. The SIGHUP handler just sets ConfigReloadPending which PostgresMain() then processes:
/* * (6) check for any other interesting events that happened while we * slept. */ if (ConfigReloadPending) { ConfigReloadPending = false; ProcessConfigFile(PGC_SIGHUP); }
which'll then, in turn, send out ParameterStatus messages for changed GUC_REPORT GUCs.
I was wondering a while ago - can't we just set our own proc's latch here, so we wake up and send it earlier if we're in the idle main loop?