Width of SubTransactionId (hello Postgres PRO)

On Thu, Oct 28, 2021 at 10:29:52AM -0400, Chapman Flack wrote:

Hi,

According to a reported PL/Java issue [0], SubTransactionId in
Postgres PRO EE 13 has become a typedef uint64 rather than uint32.

What are the plans for this type upstream? I notice it is still uint32
here, even for 14. Are there plans for it to become uint64 at some point?
Or to become something else entirely?

I am deliberating whether I should just make the Java type 64 bits and say
"thereifixedit", or if some other approach would be more futureproof.

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.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

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]https://docs.oracle.com/en/java/javase/12/docs/api/java.sql/java/sql/Savepoint.html#method.detail

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.

Regards,
-Chap

[0]: https://docs.oracle.com/en/java/javase/12/docs/api/java.sql/java/sql/Savepoint.html#method.detail
https://docs.oracle.com/en/java/javase/12/docs/api/java.sql/java/sql/Savepoint.html#method.detail

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@momjian.us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.