Re: Recovery conflict monitoring
От | Magnus Hagander |
---|---|
Тема | Re: Recovery conflict monitoring |
Дата | |
Msg-id | AANLkTims5bZLD0TNLaiws3n-23Y-E2GFuM_w=qTnS-xa@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Recovery conflict monitoring (Greg Smith <greg@2ndquadrant.com>) |
Список | pgsql-hackers |
On Mon, Jan 3, 2011 at 11:35, Greg Smith <greg@2ndquadrant.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/
В списке pgsql-hackers по дате отправления: