Re: Usage of epoch in txid_current - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Usage of epoch in txid_current
Date
Msg-id CAPpHfdv5EyXmL++6EC0Lkt96CBtwZkQG-xt4_ZKNnjnrVcwKPg@mail.gmail.com
Whole thread Raw
In response to Re: Usage of epoch in txid_current  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jun 24, 2019 at 8:43 PM Alvaro Herrera <alvherre@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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Commitfest 2019-07, the first of five* for PostgreSQL 13
Next
From: Alexander Korotkov
Date:
Subject: Re: SQL/JSON path issues/questions