Skip site navigation (1) Skip section navigation (2)

Re: PATCH: regular logging of checkpoint progress

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Magnus Hagander" <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: regular logging of checkpoint progress
Date: 2011-09-02 20:04:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Tomas Vondra" <tv(at)fuzzy(dot)cz> writes:
> On 2 Z 2011, 21:23, Tom Lane wrote:
>> 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.

Your requirements seem sufficiently slippery that I don't think you've
thought them through very well.  As far as I can see, the proposed patch
will mostly result in bloating the postmaster log with repetitive
information of next to no value.  I can see the reason for wanting to
know what the system is doing right now, and I can see the reason for
wanting aggregatable statistics so that you can tell over time whether
your settings need to be adjusted.  I don't see the value in a lot of
"10% done" log entries --- there is essentially no historical value in
such, IMO, because they don't correspond to any user-level activity.
(Which is what distinguishes this from, say, log_connections or
log_statements.)  The fact that you can't figure out a reasonable
frequency for making the entries is a symptom of the design being wrong
at its core.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-09-02 20:10:30
Subject: Re: postgresql.conf archive_command example
Previous:From: Andrew DunstanDate: 2011-09-02 20:00:34
Subject: Re: pg_upgrade automatic testing

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group