On 2 Září 2011, 20:48, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On fre, 2011-09-02 at 17:02 +0200, Tomas Vondra wrote:
>>> Why is it inappropriate solution? There's a log_checkpoints GUC that
>>> drives it and you can either get basic info (summary of the checkpoint)
>>> or
>>> detailed log (with a lower log level).
>
>> If a user is forced to change the log level to get at one particular
>> piece of information, they will then also turn on countless other log
>> events on that level, which is annoying.
>
> 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.
Yes, the GUC seems inevitable. I'm still working on the verbosity for
different checpoint typees, but I think 5 seconds for xlog and 10% for
timed checkpoint is a reasonable setting.
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.
For example I'd like to have this information in cases when the checkpoint
never finishes - for example when performing automated benchmarks. I
sometimes just kill the database (I need to rebuild it from scratch for
the next run) so I don't get any checkpoint message at all. Waiting for
the checkpoint would significantly increase the time for each run and thus
for the whole benchmark. With one run that probably is not a problem, with
360 runs each minute makes a big difference.
Tomas