From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: MultiXact truncation, startup et al. |
Date: | 2013-11-29 00:40:19 |
Message-ID: | 20131129004019.GA5645@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-11-28 19:23:29 -0500, Robert Haas wrote:
> On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > So, I've done this for 9.3+ for now. Testing around that turned up that
> > our current way to schedule anti mxid wraparounds doesn't really work:
> > 1) autovacuum.c knows about such vacuums, but vacuum.c doesn't. Leading
> > to a long cycle of partial vacuums that don't increase relminmxid.
> > 2) Parts of the code used 200mio as a hardcoded constant, others used
> > autovacuum_freeze_max_age.
> >
> > 0001 fixes the vacuum scheduling and is applicable to 9.3+,
>
> multiTableLimit is a bad name for whatever concept this is supposed to
> represent. It does not involve multiple tables.
It's the freezeTableLimit equivalent for multixacts. I haven't named it
multiFreezeTableLimit because multixacts don't actually have a concept
of freezing - and in that context I didn't see much danger for it to be
understood to apply to multiple tables.
I'll try to think of a better name.
> vacuum_set_xid_limits now has multiXactCutoff, multiTableLimit, and
> mxLimit, and there's no explanation of what the are.
Well, neither have the plain xid variants. Not that that's good, but
it's not this patches fault.
I'd be happy to provide a separate patch that adds documentation for
each of them - I've wondered often enough about their meaning to make it
rather worthwhile.
> > 0002 re-adds pg_multixact truncation during crash recovery. The current
> > code will only work on 9.3+, but if it's deemed acceptable I can
> > backport it to earlier versions. I am not sure if it's worth backporting
> > it 9.0 given it has neither HS nor SR?
>
> Huh?
That should have been a < 9.0 aka. 8.4.
Patch 02 has changed its shape slightly since the version I posted here,
because it's a prerequisite for the fix for the multixact bugs around
heap_freeze_tuple() and heap_tuple_needs_freeze() I've written about
nearby. I think Alvaro plans to work over my fixes to make them look
nice enough and commit them soonish.
Should somebody want to look into it
http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/multixact-handling
contains the fixes.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2013-11-29 02:04:10 | Re: [RFC] overflow checks optimized away |
Previous Message | Robert Haas | 2013-11-29 00:23:29 | Re: MultiXact truncation, startup et al. |