From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Width of SubTransactionId (hello Postgres PRO) |
Date: | 2021-10-28 16:34:29 |
Message-ID: | 20211028163429.GB32290@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 28, 2021 at 12:02:30PM -0400, Chapman Flack wrote:
> On 10/28/21 10:37, Bruce Momjian wrote:
>
> > I know of no plans to implement 64-bit transaction ids in community
> > Postgres because of the longer tuple header and file format changes.
> > It is discussed occasionally though.
>
> Is there anything you can use a SubTransactionId for outside of C code?
>
> PL/Java interacts with these things through BeginInternalSubTransaction(),
> ReleaseCurrentSubTransaction(), or RollbackAndReleaseCurrentSubTransaction()
> in C.
>
> It also has been obeying the letter of the JDBC spec by implementing
> a method that can return it to the caller (as a Java 32-bit int, oops,
> so decreed by the spec). [0]
>
> But as I think about it, I am not sure there is anything interesting or
> useful a Java caller could do with a SubTransactionId anyway. I mean, does
> it even appear in a statistics view or SQL-exposed function anywhere? I see
> there is a top-level backend_xid in pg_stat_activity, but is there any
> exposure of SubTransactionIds anywhere?
>
> Everything you can do with a Savepoint in JDBC (release it or roll it back,
> what else is there?) is just a method on the Java object and you don't need
> to know its underlying id.
That is my assumption too.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-10-28 16:37:49 | Re: inefficient loop in StandbyReleaseLockList() |
Previous Message | Tom Lane | 2021-10-28 16:14:06 | Re: CREATEROLE and role ownership hierarchies |