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

Поиск
Список
Период
Сортировка
Искать
От
Simon Riggs
Тема
Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand
Дата
Msg-id
1298018161.2226.3986.camel@ebony
Ответ на
Список
Дерево обсуждения
Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand Simon Riggs <simon@2ndQuadrant.com>
Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand Fujii Masao <masao.fujii@gmail.com>
Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand Simon Riggs <simon@2ndQuadrant.com>
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 по дате отправления
От: Heikki Linnakangas
Дата:
От: Marko Tiikkaja
Дата:
FAQ