On 2 Září 2011, 21:23, Tom Lane wrote:
> "Tomas Vondra" <tv@fuzzy.cz> writes:
>> On 2 Z?????? 2011, 20:48, Tom Lane wrote:
>>> Yeah, if we're going to have this at all, some form of GUC control over
>>> it seems necessary. I'm still disturbed by the verbosity of the
>>> proposed output though. Couldn't we collapse the information into a
>>> single log entry per checkpoint cycle? Perhaps that would be
>>> sufficient
>>> to just let the log_checkpoints setting be used as-is.
>
>> I'm not sure what you mean by collapsing the info into a single log
>> entry?
>> That would mean I'd have to wait till the checkpoint completes, and one
>> of
>> the reasons for this patch was to get info about progress while the
>> checkpoint is running.
>
> Well, to be blunt, putting stuff into the postmaster log is entirely the
> wrong way to satify a requirement like that. If you want to expose
> progress information, it should be exposed via something dynamic like
> pg_stat_activity. What could be useful to log is statistics that people
> might want to aggregate later, and I don't immediately see a reason why
> such stats couldn't be logged just once at end of each checkpoint cycle.
The problem with pg_stat_activity is that it provides just 'current
state', no history. If you don't sample that often enough, you may
completely miss the checkpoint (and thus you'll have no info about it,
unless you enable log_checkpoints and check the log). And it's imposible
to use if you need info about something that happened in the past. And
AFAIK it does not show processes running timed checkpoints for example.
So IMHO it's unusable for what I'm trying to achieve.
Tomas
