Hi, Am Donnerstag, den 02.10.2014, 15:21 +0200 schrieb Michael Banck: > we have seen repeatedly that users can be confused about why PostgreSQL > is not shutting down even though they requested it. Usually, this is > because `log_checkpoints' is not enabled and the final checkpoint is > being written, delaying shutdown. As no message besides "shutting down" > is written to the server log in this case, we even had users believing > the server was hanging and pondering killing it manually.
There were some comments that this might not actually be the case and/or that the postmaster was simply waiting for clients to disconnect due to smart shutdown being invoked. About the former, it might be possible to hook into the checkpoint code and try to estimate how much I/O is to be written, and decide on some threshold above which a warning is issued, but this looks rather fragile so I won't try to tackle it now. About the latter, this is a valid concern, and I decided to add a WARNING in this case (if normal clients are connected), thus moving into the "additional logging on shutdown" territory. The other point was changing the default shutdown method and/or the default for the log_checkpoints parameter. The former has not been discussed much and the latter was contentious - I won't touch those either. And even if the defaults are changed, old installations might still carry the old defaults or DBAs might change them for whatever reasons, so ISTM additional logging is rather orthogonal to that. Finally, I am not convinced changing the pg_ctl logging is worthwhile. I have updated the initial patch with the following: (i) the message got changed to mention that this is a shutdown checkpoint, (ii) the end of the shutdown checkpoint is logged as well and (iii) if normal clients are connected during smart shutdown, a warning is logged. I'll attach it to the next commitfest and see whether anybody likes it. Michael -- Michael Banck Projektleiter / Berater Tel.: +49 (2161) 4643-171 Fax: +49 (2161) 4643-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 5a4dbb9..e6f03fe 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -8085,10 +8085,14 @@ CreateCheckPoint(int flags) /* * If enabled, log checkpoint start. We postpone this until now so as not - * to log anything if we decided to skip the checkpoint. + * to log anything if we decided to skip the checkpoint. If we are during + * shutdown and checkpoints are not being logged, add a log message that a + * checkpoint is to be written and shutdown is potentially delayed. */ if (log_checkpoints) LogCheckpointStart(flags, false); + else if (shutdown) + ereport(LOG, (errmsg("waiting for shutdown checkpoint ..."))); TRACE_POSTGRESQL_CHECKPOINT_START(flags); @@ -8311,6 +8315,12 @@ CreateCheckPoint(int flags) /* Real work is done, but log and update stats before releasing lock. */ LogCheckpointEnd(false); + /* On shutdown, log a note about the completed shutdown checkpoint even + * if log_checkpoints is off. + */ + if (!log_checkpoints && shutdown) + ereport(LOG, (errmsg("shutdown checkpoint completed"))); + TRACE_POSTGRESQL_CHECKPOINT_DONE(CheckpointStats.ckpt_bufs_written, NBuffers, CheckpointStats.ckpt_segs_added, diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c index ce920ab..99c8911 100644 --- a/src/backend/postmaster/postmaster.c +++ b/src/backend/postmaster/postmaster.c @@ -2405,6 +2405,11 @@ pmdie(SIGNAL_ARGS) if (WalWriterPID != 0) signal_child(WalWriterPID, SIGTERM); + /* check whether normal children are connected and log a warning if so */ + if (CountChildren(BACKEND_TYPE_NORMAL) != 0) + ereport(WARNING, + (errmsg("waiting for clients to disconnect ... "))); + /* * If we're in recovery, we can't kill the startup process * right away, because at present doing so does not release
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers