On 2019-Jun-22, Alexander Korotkov wrote: > 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.
I think enlarging multixacts to 64 bits is a terrible idea. I would rather get rid of multixacts completely; zheap is proposing not to use multixacts at all, for example. The amount of bloat caused by pg_multixact data is already pretty bad ... because of which requiring pg_multixact to be rewritten by pg_upgrade would cause a severe slowdown for upgrades. (It worked for FSM because the volume is tiny, but that's not the case for multixact.) I think the pg_upgrade problem can be worked around by creating a new dir pg_multixact64 (an example) which is populated from the upgrade point onwards; so you keep the old data unchanged, and new multixacts use the new location, but the system knows to read the old one when reading old tuples. But, as I said above, I would rather not have multixacts at all. Another idea: create a new table AM that mimics heapam (I think ß-heap "eszett-heap" is a good name), except that it reuses zheap's idea of keeping "transaction locks" separately for tuple locks rather than multixacts; heapam continues to use 32bits multixact. Tables can be migrated from heapam to ß-heap (alter table ... set access method) to incrementally reduce reliance on multixacts going forward. No need for pg_upgrade-time disruption. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services