On Thu, Apr 2, 2020 at 2:47 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > > > > > On Apr 2, 2020, at 11:01 AM, Andres Freund <and...@anarazel.de> wrote: > > > >> > >> Hmm, for some reason I had it in my head that we would make these use an > >> "epoch/val" output format rather than raw uint64 values. > > > > Why would we do that? IMO the goal should be to reduce awareness of the > > 32bitness of normal xids from as many places as possible, and treat them > > as an internal space optimization. > > I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs as an > internal implementation and storage detail only, but we still have user > facing views that don't treat it that way. pg_stat_get_activity still > returns backend_xid and backend_xmin as 32-bit, not 64-bit. Should this > function change to be consistent? I'm curious what the user experience will > be during the transitional period where some user facing xids are 64 bit and > others (perhaps the same xids but viewed elsewhere) will be 32 bit. That > might make it difficult for users to match them up.
Agreed. The "benefit" (at least in the short term) of using the epoch/value style is that it makes (visual, at least) comparison with other (32-bit) xid values easier. I'm not sure if that's worth it, or if it's worth making a change depend on changing all of those views too. James
