On Tue, Jul 17, 2018 at 1:55 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2018-07-15 16:41:35 -0400, Tom Lane wrote: >>> Andres Freund <and...@anarazel.de> writes: >>>> On 2018-07-09 19:56:25 -0400, Tom Lane wrote: >>>>> Or, perhaps, use a struct in assert builds and int64 otherwise? >>>>> You could hide the ensuing notational differences in macros. > >>> [ bunch of test results ] >>> Offhand it would seem that we can get away with struct wrappers >>> on any platform where performance is really of concern today. > >> Cool, thanks for checking!
+1 Here's a new version. I did some cosmetic clean-up, and I dropped the changes to pg_controldata output, replication epoch/xid processing code and various similar non-essential changes. For this patch I want just the new type + next xid generator + appropriate conversions. I propose that we get this committed early in the cycle. That'd maximise testing time in the tree, fix the bug identified by Amit, and leave plenty of time for later patches to use FullTransactionId in more places as appropriate. Does anyone have specific kinds of validation or testing they'd like to see? -- Thomas Munro http://www.enterprisedb.com
0001-Track-the-next-xid-using-64-bits-v5.patch
Description: Binary data