Re: pg_locks view versus prepared transactions

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pg_locks view versus prepared transactions
Дата
Msg-id 20050620210442.GA9278@surnet.cl
обсуждение исходный текст
Ответ на Re: pg_locks view versus prepared transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jun 20, 2005 at 04:18:03PM -0400, Tom Lane wrote:

> However, all you could get from ProcArray would be the database in
> which the backend is running, and maybe the owning user's ID if we
> cared to expend the extra space to store it there.  We're certainly
> not going to add current_query or any such thing into that array.

You could show the current transaction Id, which is also useful.
(Presently there's no way to know even a backend's own TransactionId,
and people is suggested to use hacks like insert a row in a table and
check its xmin.)

Maybe we could add an adittional view, with all the info from ProcArray,
which is useful sometimes.  Then you could join that to pg_locks, and it
would work even if the statistic collector is disabled.

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
"La felicidad no es mañana. La felicidad es ahora"


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Issue with plpython write_file and read_file tests
Следующее
От: Andreas Pflug
Дата:
Сообщение: Re: [PATCHES] default database creation with initdb