From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Background Processes and reporting |
Date: | 2016-03-11 19:16:32 |
Message-ID: | 20160311191632.l2alzmzyhsu6nbq5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
We now have "Provide much better wait information in pg_stat_activity"
and "Add a generic command progress reporting facility" making it easier
to provide insight into the system.
While working on the writeback control / checkpoint sorting patch I'd
the following statement in BufferSync()'s main loop:
fprintf(stderr, "\33[2K\rto_scan: %d, scanned: %d, %%processed: %.2f, %%writeouts: %.2f",
num_to_scan, num_processed,
(((double) num_processed) / num_to_scan) * 100,
((double) num_written / num_processed) * 100);
which basically printed the progress of a checkpoint, and some
additional detail to stderr. Quite helpful to see whether progress is
"unsteady".
Obviously that's not something that could be committed.
So I'm wondering how we can make it possible to use the aforementioned
"progress reporting facility" to monitor checkpoint progress. To which
Robert replied on IM:
"it wouldn't quite help with that because the checkpointer doesn't show
up as a regular backend"
It seems rather worthwhile to think about how we can expand the coverage
of progress tracking to other types of background processes.
Similarly for the wait event stuff - checkpointer, wal writer,
background writer are in many cases processes that very often are
blocked on locks, IO and such. Thus restricting the facility to
database connected processes seems like a loss.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-03-11 19:31:00 | Re: [PATH] Correct negative/zero year in to_date/to_timestamp |
Previous Message | David Steele | 2016-03-11 19:10:14 | Re: insufficient qualification of some objects in dump files |