Re: Recovery conflict monitoring - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Recovery conflict monitoring
Date
Msg-id 1294010599.2090.4121.camel@ebony
Whole thread Raw
In response to Re: Recovery conflict monitoring  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Recovery conflict monitoring  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, 2010-12-27 at 14:39 +0100, Magnus Hagander wrote:
> On Thu, Dec 23, 2010 at 13:09, Magnus Hagander <magnus@hagander.net> wrote:
> > This patch adds counters and views to monitor hot standby generated
> > recovery conflicts. It extends the pg_stat_database view with one
> > column with the total number of conflicts, and also creates a new view
> > pg_stat_database_conflicts that contains a breakdown of exactly what
> > caused the conflicts.
> >
> > Documentation still pending, but comments meanwhile is of course appreciated ;)
> 
> Heikki pointed out over IM that it's pointless to count stats caused
> by recovery conflict with drop database - since we drop the stats
> record as soon as it arrives anyway. Here's an updated patch that
> removes that, and also adds some documentation.

I like the patch, well inspired, code in the right places AFAICS. No
code comments at all.

Couple of thoughts: 

* are we safe to issue stats immediately before issuing FATAL? Won't
some of them get lost?

* Not clear what I'd do with database level information, except worry a
lot. Maybe an option to count conflicts per user would be better, since
at least we'd know exactly who was affected by those. Just an idea.

* Would it better to have a log_standby_conflicts that allowed the
opportunity to log the conflicting SQL, duration until cancelation etc?

I'd rather have what you have than nothing at all though... the new
hot_standby_feedback mode should be acting to reduce these, so it would
be useful to have this patch enabled for testing that feature.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: How to know killed by pg_terminate_backend
Next
From: Simon Riggs
Date:
Subject: Re: page compression