pgsql: Add pg_stat_archiver statistics view.

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

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers