Re: Proposal: Expose oldest xmin as SQL function for monitoring

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal: Expose oldest xmin as SQL function for monitoring
Дата
Msg-id 30712.1585854944@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal: Expose oldest xmin as SQL function for monitoring  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2020-04-01 19:57:32 -0400, Tom Lane wrote:
>> Agreed, but just knowing what the oldest xmin is doesn't help you
>> find *where* it is.  Maybe what we need is a view showing all of
>> these potential sources of an old xmin.

> +1.  This would be extermely useful. It's a very common occurance to
> have to ask for a number of nontrivial queries when debugging xmin
> related bloat issues.

> Having a view that lists something like:

> - shared xmin horizon
> - pid of backend with oldest xmin across all backends

I was envisioning a view that would show you *all* the active processes
and their related xmins, then more entries for all active replication
slots, prepared xacts, etc etc.  Picking out the ones causing trouble is
then the user's concern.  If the XID column is actually fullXid then
sorting, aggregating, etc. is easy.

The point about database-local vs not is troublesome.  Maybe two
such views would be needed?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: control max length of parameter values logged
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Should we add xid_current() or a int8->xid cast?