Idea: closing the loop for "pg_ctl reload"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Idea: closing the loop for "pg_ctl reload"
Date: 2015-02-20 01:26:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bug #12788 reminded me of a problem I think we've discussed before:
if you use "pg_ctl reload" to trigger reload of the postmaster's
config files, and there's something wrong with those files, there's
no warning to you of that. The postmaster just bleats to its log and
keeps running. If you don't think to look in the log to confirm
successful reload, you're left with a time bomb: the next attempt
to restart the postmaster will fail altogether because of the bad
config file.

I commented in the bug thread that there wasn't much that pg_ctl
could do about this, but on reflection it seems like something we
could fix, because pg_ctl must be able to read the
file in order to issue a reload signal. Consider a design like this:

1. Extend the definition of the file to add another
line, which will contain the time of the last postmaster configuration
load attempt (might as well be a numeric Unix-style timestamp) and
a boolean indication of whether that attempt succeeded or not.

2. Change pg_ctl so that after sending a reload signal, it sleeps
for a second and checks for a change in the config load timestamp
(repeat as necessary till timeout). Once it sees the timestamp
change, it's in a position to report success or failure using the
boolean. I think this should become the default behavior, though
you could define -W to mean that there should be no wait or feedback.

It's tempting to think of storing a whole error message rather than
just a boolean, but I think that would complicate the pidfile definition
undesirably. A warning to look in the postmaster log ought to be
sufficient here.

For extra credit, the pg_reload_conf() function could be made to behave

I don't have the time to pursue this idea myself, but perhaps someone
looking for a not-too-complicated project could take it on.

regards, tom lane


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-02-20 01:58:11 Re: Exposing the stats snapshot timestamp to SQL
Previous Message Stephen Frost 2015-02-19 23:39:45 Re: Allow "snapshot too old" error, to prevent bloat