Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand
Date: 2011-02-18 08:36:01
Message-ID: 1298018161.2226.3986.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, 2011-02-18 at 11:44 +0900, Fujii Masao wrote:
> > This begs the questions "what is the xmin of all the normal
> backends?"
> > and "Whats is the xmin of prepared transactions?" as well. I wasn't
> sure > that we should expose that information for walsenders when we
> don't do > it for everybody else. If we do it would require major
> sections in the > docs explaining it all, etc..
>
> We can *presume* which backend (or prepared transaction) unexpectedly
> prevents VACUUM by seeing pg_stat_activity (or pg_prepared_xacts) and
> checking whether there is long-running transaction. But there is no
> way to presume which standby does that, I'm concerned.

Currently there is no information available to users about xmin.

It isn't any *harder* to work out standby xmins than it is to work out
prepared transaction xmins or other backend xmins. For example, we don't
show which transactions use serializable mode on pg_stat_activity and so
we might make the mistake of reading the last statement start time
rather than the last transaction start time.

I see it as a major piece of work to add xmin in *all* the right places
and to fully document how to use that information as a user. The debug
information at DEBUG2 is sufficient to show the code works and to debug
issues if needed.

I agree with you that it would be nice to have a "which thing is
bloating my tables" device, but I'm not assuming the responsibility to
create such a thing and fully document it, and definitely not Right Now.

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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Magnus Hagander 2011-02-18 11:05:32 pgsql: Properly initialize variables
Previous Message Itagaki Takahiro 2011-02-18 05:34:25 pgsql: Fix an uninitialized field in DR_copy.

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2011-02-18 08:39:18 Re: Transaction-scope advisory locks
Previous Message Heikki Linnakangas 2011-02-18 07:27:54 Re: Fix for Index Advisor related hooks