Hi! On Mon, Jun 24, 2019 at 6:27 PM Andres Freund <and...@anarazel.de> wrote: > On June 24, 2019 8:19:13 AM PDT, Robert Haas <robertmh...@gmail.com> wrote: > >On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov > ><a.korot...@postgrespro.ru> wrote: > >> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro <thomas.mu...@gmail.com> > >wrote: > >> > Thanks for the reviews! Pushed. > >> > >> Any ideas we should move towards 64-bit xids in more places? That > >has > >> been discussed several times already. I think last time it was > >> discussed in person during FOSDEM PGDay 2018 Developer Meeting [1]. > >> There we've discussed that it probably doesn't worth it to change > >> 32-bit on-disk xids in heap. It's better to leave existing heap "as > >> is", but allow other pluggable table access methods to support 64-bit > >> xids. Given now we have pluggable table access methods, we may build > >> a plan on full support of 64-bit xids in core. > >> > >> In my vision sketchy plan may look like this. > >> > >> 1. Change all non-heap types of xids from TransactionId to > >> FullTransactionId. > > > >I think it's fine to replace TransactionId with FullTransactionId > >without stressing about it too much in code that's not that heavily > >trafficked. However, I'm not sure we can do that across the board. For > >example, converting snapshots to use 64-bit XIDs would mean that in > >the worst case a snapshot will use twice as many cache lines, and that > >might have performance implications on some workloads. > > We could probably expand the transaction IDs on access or when computing them > for most of these, as usually they'll largely be about currently running > transactions. It e.g. seems sensible to keep the procarray at 32 bit xids, > expand xmin/xmax to 64 when computing snapshots, and leave the snapshot's > transaction ID array at 32xids. That ought to be an negligible overhead.
I see, replace TransactionId with FullTransactionId just everywhere doesn't look like good idea. Given now we have pluggable table AMs, new table AMs may not have data wraparound problem. For instance, table AM could store xids 64-bit internally, and convert them to 32-bit on-the-fly. If xid is too old for conversion, just replace it with FrozenTransactionId. So, the restriction we really have now is that running xacts and active snapshots should fit 2^31 range. Turning Snapshot xmin/xmas into 64-bit will soften this restriction, then just running xacts should fit 2^31 range while snapshots could be older. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company