Re: Recovery conflict monitoring

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery conflict monitoring
Date: 2011-01-02 23:23:19
Message-ID: 1294010599.2090.4121.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)hagander(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-01-02 23:36:02 Re: page compression
Previous Message Tatsuo Ishii 2011-01-02 23:17:42 Re: How to know killed by pg_terminate_backend