Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs
| От | Pavlo Golub |
|---|---|
| Тема | Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs |
| Дата | |
| Msg-id | em14322cd4-f84a-485d-b8d8-7dc2e2c58035@cybertec.at обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs (Henson Choi <assam258@gmail.com>) |
| Список | pgsql-hackers |
Hello. Thanks for the review. > >Only pg_locks has it. And you can already get your VXID from there: > > SELECT virtualtransaction FROM pg_locks > WHERE pid = pg_backend_pid() LIMIT 1; While it is true that pg_locks contains the virtual transaction information, I believe there are strong technical reasons to expose this directly via a function. First of all, querying pg_locks is expensive. By contrast, pg_current_vxact_id() is a practically free O(1) read from MyProc. The %v log placeholder is the specific identifier for individual transaction executions (including read-only ones where no permanent XID is assigned). PIDs (%p) are session-scoped and too coarse for helping debug specific transactions in connection-pooled environments. This function allows applications to easily obtain the ID needed to correlate with server logs. We already provide fast accessors for other identifiers like pg_backend_pid() and pg_current_xact_id(). Additionally, PostgreSQL often provides utility functions that overlap with other commands or views to improve developer experience (e.g., pg_notify() vs NOTIFY, pg_sleep() vs pg_sleep_for() vs pg_sleep_until()). It feels consistent to offer a simple accessor rather than requiring a complex query against a system view. Best regards, Pavlo Golub
В списке pgsql-hackers по дате отправления: