On 16 October 2014 20:31, Michael Banck <michael.banck@credativ.de> wrote:
> I'll attach it to the next commitfest and see whether anybody likes it.
Not much...
We may decide we wanted to always-log shutdown checkpoints. I'm
neutral about that, but I can see the logic. But if we did, we would
use exactly the same log message as if log_checkpoints = on. Having
two different message texts is just confusing.
I don't see the point of logging "waiting for clients to disconnect"
since we might not wait very long. We do already log the type of
shutdown received.
A few things seem worth pursuing...
* Logging a message that shows how many buffers need to be written for
a shutdown checkpoint. (We might even store some info that allows us
to estimate a time to shutdown, later). At present the "starting:
checkpoint shutdown" isn't much use. I can see we could split
CheckpointGuts() into two, so we mark the buffers first, then report
how many there are to write, then go back to do the writing and fsync
in part two.
* Introducing a new shutdown mode that is genuinely "smart". We send
all backends a signal that will disconnect them *only* if they are
idle and not in a transaction. I've never thought the current smart
mode deserved its name.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
