"Tomas Vondra" <t...@fuzzy.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
