Thread: pgsql: Add pg_stat_archiver statistics view.
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/9132b189bf5589591cb63fef7952842b772e4fe6 Modified Files -------------- doc/src/sgml/monitoring.sgml | 67 +++++++++++++++++++ src/backend/catalog/system_views.sql | 11 ++++ src/backend/postmaster/pgarch.c | 21 +++--- src/backend/postmaster/pgstat.c | 121 ++++++++++++++++++++++++++++++++-- src/backend/utils/adt/pgstatfuncs.c | 69 +++++++++++++++++++ src/include/catalog/pg_proc.h | 2 + src/include/pgstat.h | 34 +++++++++- src/include/postmaster/pgarch.h | 13 ++++ src/test/regress/expected/rules.out | 8 +++ 9 files changed, 327 insertions(+), 19 deletions(-)
Fujii Masao <fujii@postgresql.org> writes:
> Add pg_stat_archiver statistics view.
> This view shows the statistics about the WAL archiver process's activity.
For the record, this commit should certainly have included a catversion.h
bump.
Usually it's the committer's responsibility to add that when necessary;
we don't ask people to include it in submitted patches because they'd
inevitably get patch conflicts depending on what order things get
committed in.
There are a couple of rules of thumb about when to increase catversion:
* system catalog contents no longer consistent with backend executable
(in this case, pg_proc.h versus the set of functions actually present)
* regression tests would not pass without a fresh initdb (rules.out
change makes that true here)
regards, tom lane
On Wed, Jan 29, 2014 at 5:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Fujii Masao <fujii@postgresql.org> writes: >> Add pg_stat_archiver statistics view. >> This view shows the statistics about the WAL archiver process's activity. > > For the record, this commit should certainly have included a catversion.h > bump. > > Usually it's the committer's responsibility to add that when necessary; > we don't ask people to include it in submitted patches because they'd > inevitably get patch conflicts depending on what order things get > committed in. > > There are a couple of rules of thumb about when to increase catversion: > > * system catalog contents no longer consistent with backend executable > (in this case, pg_proc.h versus the set of functions actually present) > > * regression tests would not pass without a fresh initdb (rules.out > change makes that true here) Sorry, that's definitely my mistake. I know that rule, but I just completely forgot to do that... Since 105639900bf83fd3e3eb5b49f49b4d74d6347b9b increased the catalog version, I don't increase that again for now. Regards, -- Fujii Masao
Hi,
On 2014-01-28 17:59:12 +0000, Fujii Masao wrote:
> Add pg_stat_archiver statistics view.
>
> This view shows the statistics about the WAL archiver process's activity.
>
> Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
As coverity notest the following lines of code:
if (archiver_stats->last_failed_wal == 0)
nulls[4] = true;
else
values[4] = CStringGetTextDatum(archiver_stats->last_failed_wal);
won't work as intended since last_failed_wal is an array of chars and
thus will never be 0 (which should be NULL if so).
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Feb 4, 2014 at 6:20 AM, Andres Freund <andres@2ndquadrant.com> wrote: > Hi, > > > On 2014-01-28 17:59:12 +0000, Fujii Masao wrote: >> Add pg_stat_archiver statistics view. >> >> This view shows the statistics about the WAL archiver process's activity. >> >> Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me. > > As coverity notest the following lines of code: > if (archiver_stats->last_failed_wal == 0) > nulls[4] = true; > else > values[4] = CStringGetTextDatum(archiver_stats->last_failed_wal); > won't work as intended since last_failed_wal is an array of chars and > thus will never be 0 (which should be NULL if so). Thanks for the report! I found last_archived_wal has also the same problem. Fixed. Regards, -- Fujii Masao