On Mon, Jun 24, 2019 at 8:43 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > 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.
We need multixacts to store row-level locks information. I remember they weren't crash-safe some time ago; because we basically don't need lock information about previous server run: all that locks are for sure released. Due to some difficulties we finally made them crash-safe (I didn't follow that in much details). But what about discarding mulixacts on pg_upgrade? Is it feasible goal? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
