On 16 October 2014 20:31, Michael Banck <michael.ba...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
