Re: pg_locks view versus prepared transactions
От | Merlin Moncure |
---|---|
Тема | Re: pg_locks view versus prepared transactions |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3415C2B25@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | pg_locks view versus prepared transactions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_locks view versus prepared transactions
Re: pg_locks view versus prepared transactions |
Список | pgsql-hackers |
> I think the minimum thing we ought to do about this is add an XID > column to pg_locks to show the transaction ID holding each lock. > Then you could join that to pg_prepared_xacts to see what's what. > I was also wondering about adding a current-XID column to > pg_stat_activity, and encouraging people to join pg_locks and > pg_stat_activity on XID instead of PID. That would be awesome. Is there any performance penalty to do this? (I don't care about performance of pg_lock_status function execution, just overall overhead). > Ultimately we should maybe even remove PID from pg_locks, but probably > for backwards compatibility it'd have to be deprecated for a release > or two first. It is interesting to note that systems with stats disabled are unable to get lock owner information in this case (so what?). Merlin
В списке pgsql-hackers по дате отправления: