From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Subject: | Re: Usage of epoch in txid_current |
Date: | 2019-06-21 23:01:04 |
Message-ID: | CAPpHfdt45K-JVmg=Re7jp3QNFn3pEkZkSLGpagjuGoG+HRcS3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)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. But in shared memory change TransactionId to
pg_atomic_uint64 in order to guarantee atomicity of access, which we
require in multiple places.
2. Also introduce FullMultixactId, and apply to MultixactId the
similar change as #1.
3. Change SLRU on-disk format to handle 64-bit xids and multixacts.
In particular make SLRU page numbers 64-bit too. Add SLRU upgrade
procedure to pg_upgrade.
4. Change relfrozenxid and relminmxid to something like rellimitxid
and rellimitmxid. So, we don't imply there is restriction of 32-bit
xids. Instead, we let table AM place (or don't place) a limit to
advancing nextXid, nextMultixact.
5. Table AM API would be switched to 64-bit xids/multixacts, while
heap will remain using 32-bit. So, heap should convert 32-bit xid
value to 64-bit basing on nextXid/nextMultixact. Assuming we set
rellimitxid and rellimitmxid for relation as oldestxid + 2^32 and
oldestmxid + 2^32, we may safely assume the 32-bit values of
xids/multixacts are in 2^32 range before nextXid/nextMultixact.
Thanks to this even in heap we would be able to operate 2^32
xids/multixacts simultaneously instead of 2^31 we have now.
So, this is how I see the possible plan. I would be glad to see a feedback.
Unfortunately, I don't have enough time to implement all of this. But
I think there are many interested parties in finally having 64-bit
xids in core. Especially assuming we now have pluggable table AMs,
and it would be ridiculous to spear limitation of 32-bit xids to new
table AMs.
Links
1. https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2018_Developer_Meeting
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2019-06-21 23:53:53 | Re: \describe* |
Previous Message | Tom Lane | 2019-06-21 22:54:52 | Re: POC: Cleaning up orphaned files using undo logs |