Re: Expose checkpoint start/finish times into SQL.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Expose checkpoint start/finish times into SQL.
Date: 2008-04-04 20:16:09
Message-ID: 7659.1207340169@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> These kind of things can be monitored externally very easily, say by
> Nagios, when the values are available via the database. If you have to
> troll the logs, it's quite a bit harder to do it.

> I'm not sure about the right values to export -- last checkpoint start
> time is the most obvious idea, but I would also suggest exporting last
> checkpoint end, or NULL if the checkpoint is ongoing; and also previous-
> to-last checkpoint start and end.

Any Nagios-style monitoring would have to watch checkpoint end (and
we'd better define that field as only updating at *successful*
checkpoint end). Consider the case where some dirty buffer has a
persistent write failure condition.

I'm almost inclined to say that the patch shouldn't expose checkpoint
start at all, just to make sure people won't get this wrong. We've
pretty thoroughly trashed the notion that looking at the interval is
helpful anyway.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Teodor Sigaev 2008-04-04 20:20:23 Partial match in GIN
Previous Message Pavel Stehule 2008-04-04 20:06:07 plpgsql CASE statement