Re: Expose checkpoint start/finish times into SQL. - Mailing list pgsql-patches

From Tom Lane
Subject Re: Expose checkpoint start/finish times into SQL.
Date
Msg-id 791.1207276395@sss.pgh.pa.us
Whole thread Raw
In response to Re: Expose checkpoint start/finish times into SQL.  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: Expose checkpoint start/finish times into SQL.  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Expose checkpoint start/finish times into SQL.  (Theo Schlossnagle <jesus@omniti.com>)
List pgsql-patches
Robert Treat <xzilla@users.sourceforge.net> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 3. As of PG 8.3, the bgwriter tries very hard to make the elapsed time
> of a checkpoint be just about checkpoint_timeout *
> checkpoint_completion_target, regardless of load factors.  So unless
> your settings are completely broken, measuring the actual time isn't
> going to tell you much.

> How does one measure when the bgwriter is failing at this effort?

Well, not with *this* patch.  At least not without adding a lot of
infrastructure on top of it, and I'm failing to see why you'd build
such infrastructure in order to track just two numbers that are of
uncertain value.

JD seems to be on record that the existing logging mechanism sucks
and he needs something else.  That's fine, but I think it means that
we need to improve logging in general, not invent a single-purpose
mechanism for logging checkpoint times.

Theo claimed he had a reason for wanting to know the latest checkpoint
time, *without* any intention of time-extended tracking of that; but
he didn't say what it was.  If there is a credible reason for that
then it might justify a patch of this nature, but I don't see that
the reasons that have been stated so far in the thread hold any water.

            regards, tom lane

pgsql-patches by date:

Previous
From: Robert Treat
Date:
Subject: Re: Expose checkpoint start/finish times into SQL.
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Expose checkpoint start/finish times into SQL.