Hi,

Currently, the startup process ignores SIGHUP.

The attached patch allows the startup process to re-read config file:
when SIGHUP arrives, the startup process also receives the signal
from postmaster and reload the settings in main redo apply loop.
Obviously, this is useful to change the parameters which the startup
process may use (e.g. log_line_prefix, log_checkpoints).

Any comments welcome.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Search Discussions

  • Heikki Linnakangas at Mar 4, 2009 at 1:58 pm

    Fujii Masao wrote:
    Currently, the startup process ignores SIGHUP.

    The attached patch allows the startup process to re-read config file:
    when SIGHUP arrives, the startup process also receives the signal
    from postmaster and reload the settings in main redo apply loop.
    Obviously, this is useful to change the parameters which the startup
    process may use (e.g. log_line_prefix, log_checkpoints).
    Thanks, committed.

    The fact that bgwriter can run simultaneously with the startup process
    makes this more important than before. Otherwise if you change something
    like log_line_prefix, bgwriter will use the new setting but startup
    process will not.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Simon Riggs at Mar 5, 2009 at 9:24 am

    On Wed, 2009-03-04 at 15:58 +0200, Heikki Linnakangas wrote:
    Fujii Masao wrote:
    Currently, the startup process ignores SIGHUP.

    The attached patch allows the startup process to re-read config file:
    when SIGHUP arrives, the startup process also receives the signal
    from postmaster and reload the settings in main redo apply loop.
    Obviously, this is useful to change the parameters which the startup
    process may use (e.g. log_line_prefix, log_checkpoints).
    Thanks, committed.

    The fact that bgwriter can run simultaneously with the startup process
    makes this more important than before. Otherwise if you change something
    like log_line_prefix, bgwriter will use the new setting but startup
    process will not.
    Should we reload recovery.conf also?

    --
    Simon Riggs www.2ndQuadrant.com
    PostgreSQL Training, Services and Support
  • Fujii Masao at Mar 5, 2009 at 10:52 am
    Hi,
    On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs wrote:
    Should we reload recovery.conf also?
    I think no for now. At least the parameters which specify the recovery target
    should not be changed during recovery. On the other hand, restore_command
    maybe can be set safely, but I'm not sure if it's really useful at this time.

    Or, upcoming HS needs such capability?

    BTW, I found that backup.sgml still had the description of log_restartpoints.
    Here is the patch to remove it.

    Regards,

    --
    Fujii Masao
    NIPPON TELEGRAPH AND TELEPHONE CORPORATION
    NTT Open Source Software Center
  • Simon Riggs at Mar 5, 2009 at 11:06 am

    On Thu, 2009-03-05 at 19:52 +0900, Fujii Masao wrote:
    Hi,
    On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs wrote:
    Should we reload recovery.conf also?
    I think no for now. At least the parameters which specify the recovery target
    should not be changed during recovery. Why not?
    On the other hand, restore_command
    maybe can be set safely, but I'm not sure if it's really useful at this time.
    Not sure changing those parameters would be a bad thing. Other
    parameters can be changed, why not those?

    --
    Simon Riggs www.2ndQuadrant.com
    PostgreSQL Training, Services and Support
  • Heikki Linnakangas at Mar 5, 2009 at 11:22 am

    Simon Riggs wrote:
    On Thu, 2009-03-05 at 19:52 +0900, Fujii Masao wrote:
    Hi,
    On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs wrote:
    Should we reload recovery.conf also?
    I think no for now. At least the parameters which specify the recovery target
    should not be changed during recovery.
    Why not?
    I don't see either why it wouldn't work. As long as the new value is
    greater than the current point in recovery.

    BTW, we now have some extra safeguards (minRecoveryPoint) in place to
    prevent you from corrupting your database by moving recovery target
    backwards to a point earlier than an already recovery xlog record.
    That's not really that relevant to reloading recovery.conf on the fly,
    but it's worth noting. The documentation currently says about the
    settings in recovery.conf that "They cannot be changed once recovery has
    begun." That wording should probably be relaxed.
    On the other hand, restore_command
    maybe can be set safely, but I'm not sure if it's really useful at this time.
    Not sure changing those parameters would be a bad thing. Other
    parameters can be changed, why not those?
    It seems safe to me. It doesn't seem very useful, though. The only
    options left in recovery.conf are restore_command, and all the
    target-related options. If you want to change those, you can always stop
    the server, change the settings and restart; without hot standby there
    isn't any other backends active yet that would get upset about the shutdown.

    The main reason why reloading the main config file on SIGHUP is a good
    idea is that otherwise you get an inconsistency between the background
    writer and the startup process.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Heikki Linnakangas at Mar 5, 2009 at 11:26 am

    Fujii Masao wrote:
    BTW, I found that backup.sgml still had the description of log_restartpoints.
    Here is the patch to remove it.
    Thanks, I had put that in the Open Items list so that we remember to do
    that before release.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Tom Lane at Mar 5, 2009 at 7:50 pm

    Fujii Masao writes:
    BTW, I found that backup.sgml still had the description of log_restartpoints.
    Here is the patch to remove it.
    Applied, thanks.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 3, '09 at 7:17a
activeMar 5, '09 at 7:50p
posts8
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase