On 3/11/13 2:48 AM, Amit Kapila wrote:
1) When you change a sighup or user setting, it writes the config file
out. But it does not signal for a reload. Example:
I think we cannot guarantee even after calling pg_reload_conf(), as this is
an
asynchronous function call.
We already once had a discussion about this point and as I can understand it
is
concluded that it should not be handled. Refer the below mail:
http://www.postgresql.org/message-id/21869.1360683...@sss.pgh.pa.us
I wasn't complaining that the change isn't instant. I understand that
can't be done. But I think the signal to reload should be sent. If
people execute SET PERSISTENT, and it doesn't actually do anything until
the server is next restarted, they will be very surprised. It's OK if
it doesn't do anything for a second, or until new sessions connect,
because that's just how SIGHUP/session variables work. That's a
documentation issue. Not reloading the config at all, I think that's
going to trigger a ton of future support problems.
2 things, you want as part of this comment:
a. change the name of .auto file to persistent.auto.conf
b. new comment in beginning of persistent.auto.conf file.
Right. config/persistent.auto.conf seems like it addresses everyone's
ideas on how the file should be named. If there's a warning not to edit
it in the file, too, it would be making obvious to users what is
happening. The file handles persistent changes, it's automatically
configured, and it's a config file. Putting "postgresql" in the name
seems unnecessary to me.
The check for the include_dir entry needs to happen each time SET
PERSISTENT runs.
This can be handled, but for this we need to parse the whole postgresql.conf
file
and then give the warning. This will increase the time of SET PERSISTENT
command.
I don't think that's a problem. I can run the command 1800 times per
second on my laptop right now. If it could only run once per second,
that would still be fast enough. Doing this the most reliable way it
can be handled is the important part; if that happens to be the slowest
way, too, that is acceptable.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
