From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(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:23:29 |
Message-ID: | CA+TgmoZ-i4FKCESesrdiUtO71ZPd0MjQCU17eGpWpZ8cSBz7tQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
vacuum_set_xid_limits now has multiXactCutoff, multiTableLimit, and
mxLimit, and there's no explanation of what the are.
> 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-11-29 00:40:19 | Re: MultiXact truncation, startup et al. |
Previous Message | Andreas Karlsson | 2013-11-29 00:13:11 | Todo item: Support amgettuple() in GIN |