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. 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