From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Recovery conflict monitoring |
Date: | 2011-01-03 11:21:22 |
Message-ID: | AANLkTims5bZLD0TNLaiws3n-23Y-E2GFuM_w=qTnS-xa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 3, 2011 at 11:35, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Couple of doc suggestions:
>
> --- doc/src/sgml/high-availability.sgml
> + The number of query cancels and the reason for them can be viewed
> using
> + the <structname>pg_stat_database_conflicts</> system view on the slave
> + server.
>
> For compleness sake, this should also mention the per-database summary, even
> though I'm not sure how valuable that view is. Also, "on a standby server"
> instead of "on the slave server" here. "slave" is mentioned once as a
> synonym in high-availability.sgml once, but that's it, and there can be more
> than one standby you want to pull these stats from.
Good point, changed and added.
> *** doc/src/sgml/monitoring.sgml
> ! number of rows returned, fetched, inserted, updated and deleted, and
> ! total number of queries cancelled due to conflict with recovery.
>
> This would be clearer if it said you're talking about standby recovery here,
> and possibly that this info is only available on the standby. I could see
> someone reading this and thinking it's possible for general database crash
> recovery to produce cancelled queries, instead of the way connections are
> actually blocked until that's done.
>
> ! <entry><structname>pg_stat_database_conflicts</>
> ! <entry>One row per database, showing database OID, database name and
> ! the number of queries that have been cancelled in this database due
> to
> ! dropped tablespaces, lock timeouts, old snapshots, pinned buffers
> and
> ! deadlocks.
>
> A clarification that you're talking about standby query cancellation here
> might be helpful too. I don't think that's necessary for all of the
> detailed pg_stat_get_* functions that regular users are less likely to care
> about, just these higher level ones.
Yeah, those both make sense - I've updated the docs and am running tests ATM.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Brar Piening | 2011-01-03 11:26:30 | Re: Visual Studio 2010/Windows SDK 7.1 support |
Previous Message | Simon Riggs | 2011-01-03 11:10:40 | Re: Sync Rep Design |