| From: | Henson Choi <assam258(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs |
| Date: | 2026-01-09 03:15:21 |
| Message-ID: | CAAAe_zBUd3epVqcDAMVmLDt4-dhxVY5W09+gp5ND_P--b90eeA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2026년 1월 9일 (금) AM 9:25, Michael Paquier <michael(at)paquier(dot)xyz>님이 작성:
> On Mon, Dec 08, 2025 at 12:09:58PM +0000, Pavlo Golub wrote:
> > Virtual transaction IDs are fundamental to PostgreSQL's transaction
> > tracking,
> > appearing in pg_locks.virtualtransaction, log output via %v placeholder,
> and
> > internal transaction management. However, there's currently no direct SQL
> > function to retrieve the current VXID, forcing applications to query
> > pg_locks
> > or parse log files to obtain this information.
>
> This is replacing one SQL in a given session by another, as a session
> currently running a transaction can query itself pg_locks and match an
> entry with its own pg_backend_pid(). Hence I don't see the need for
> this function, except simplicity in retrieving a session's state with
> less characters typed at the end?
>
I see this as a tradeoff between minor convenience and negligible
addition cost.
The community should decide whether this tradeoff is worth it.
> Thoughts and opinions from others are welcome. I'm always OK to be
> outvoted.
> --
> Michael
>
Best regards,
Henson Choi
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-01-09 03:22:26 | Re: IO wait events for COPY FROM/TO PROGRAM or file |
| Previous Message | Peter Smith | 2026-01-09 03:00:20 | Re: Proposal: Conflict log history table for Logical Replication |