Re: Parameter status message not sent?

[Tatsuo Ishii]

> 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.

Thanks. I confirmed what you said by using strace attached to
backend.

One thing I noticed was, some GUC variables were sent as well even if
they were not changed.

sendto(10, "S\0\0\0\27DateStyle\0ISO, 
MDY\0S\0\0\0\23TimeZone\0Japan\0S\0\0\0#standard_conforming_strings\0on\0T\0\0\0!\0\1?column?\0\0\0\0\0\0\0\0\0\0\27\0\4\377\377\377\377\0\0D\0\0\0\v\0\1\0\0\0\0011C\0\0\0\rSELECT
 1\0Z\0\0\0\5I", 146, 0, NULL, 0) = 146

So not only standard_conforming_strings, but Datestyle and TimeZone
were sent to frontend (I only changed standard_conforming_strings in
postgresql.conf).

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

Re: Parameter status message not sent?

[Andres Freund]

Hi,

On 2018-02-14 10:42:12 +0800, Craig Ringer wrote:
> 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?

The problem is that the client doesn't really expect messages from the
server when it's idle... It's also not clear to me what the gain would
be?

Greetings,

Andres Freund

Re: Parameter status message not sent?

[Craig Ringer]

On 14 February 2018 at 10:26, Andres Freund  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

Re: Parameter status message not sent?

[Andres Freund]

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.

Greetings,

Andres Freund