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

From Simon Riggs
Subject Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand
Date
Msg-id 1298018161.2226.3986.camel@ebony
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand  (Fujii Masao <masao.fujii@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Fix for Index Advisor related hooks
Next
From: Marko Tiikkaja
Date:
Subject: Re: Transaction-scope advisory locks