Hi!
On Mon, Jun 24, 2019 at 6:27 PM Andres Freund <andres@anarazel.de> wrote:
> On June 24, 2019 8:19:13 AM PDT, Robert Haas <robertmhaas@gmail.com> wrote:
> >On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
> ><a.korotkov@postgrespro.ru> wrote:
> >> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro <thomas.munro@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/xmaxto 64 when computing snapshots, and leave the snapshot's transaction ID array at 32xids. That ought to be an
negligibleoverhead.
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