Re: Log notice that checkpoint is to be written on shutdown

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Log notice that checkpoint is to be written on shutdown
Date: 2014-11-15 22:11:29
Message-ID: CA+U5nMLDXExnbj4k58NH=Fd-CxP+Hitu+-sLMH7zs3qgOBm7dw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16 October 2014 20:31, Michael Banck <michael(dot)banck(at)credativ(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-11-15 22:51:13 PgBench's \setrandom could be better
Previous Message Simon Riggs 2014-11-15 21:36:06 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg