Re: Parameter status message not sent?

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Parameter status message not sent?
Дата
Msg-id CAMsr+YGixMhathSoTpQz1pKNh=w9070BdCs8bUdY5vi=T5vcog@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parameter status message not sent?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Parameter status message not sent?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 14 February 2018 at 10:26, Andres Freund <andres@anarazel.de> wrote:
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?

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Parameter status message not sent?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Python 3.7 support