Обсуждение: Width of SubTransactionId (hello Postgres PRO)
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. Regards, -Chap [0] https://github.com/tada/pljava/issues/376
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] 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
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.