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
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 |