Thread

Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs

Robert Haas <robertmhaas@gmail.com> — 2026-05-13T17:16:45Z

On Thu, Feb 5, 2026 at 8:13 AM Pavlo Golub <pavlo.golub@cybertec.at> wrote:
> pg_current_vxact_id() complexity is O(1) with direct memory reads and
> no locks, while querying pg_locks requires O(n) where n is the number
> of locks, among these operations are constructing tuples then
> filtering. For me it's obviously more work. The proposed function is
> essentially free compared to pg_locks querying.

I agree with this and would be inclined to accept the patch. I have
reviewed the v3 patch and I didn't see anything wrong with it. I think
it could be committed if we were not in feature freeze, and of course
provided that we had consensus.

> I'd appreciate thoughts from others in the community on whether this
> reasoning is compelling.

I think the only thing I find slightly less than compelling about this
reasoning is that it's all theoretical. If you said, look, we tried
the pg_locks method in our environment and the performance was
demonstrably bad, and then we wrote an extension that does the same
thing as this function and then the performance was good, that would
be a much stronger argument in my mind. Otherwise, someone might
hypothesize that the performance gap that you point out here, while
almost certainly read in and of itself, is not something that anyone
has a real-world reason to care about. I do sometimes have concerns
about adding a whole bunch of functions to the default install that
can theoretically be justified but in reality get very little use. In
general I think the bar for adding stuff like this should be fairly
low, but I also wonder how many people would really be sad if we were
missing, e.g., asinh() or pg_get_tablespace_ddl() or pg_sleep_until(),
just to pick a few examples of things that have failed to win my
unqualified confidence over the years.

I'm not saying any of those were necessarily bad things for us to
accept; the use case isn't nothing, and asinh() is apparently even in
the SQL standard. At the same time, I bet the percentage of installs
that will ever use any of them is real small.

-- 
Robert Haas
EDB: http://www.enterprisedb.com