Re: truncating pg_multixact/members

On Tue, Feb 11, 2014 at 5:16 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas escribió:
>> On Mon, Jan 20, 2014 at 1:39 PM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)com> wrote:
>> > * I haven't introduced settings to tweak this per table for
>> > autovacuum. I don't think those are needed. It's not hard to do,
>> > however; if people opine against this, I will implement that.
>>
>> I can't think of any reason to believe that it will be less important
>> to tune these values on a per-table basis than it is to be able to do
>> the same with the autovacuum parameters. Indeed, all the discussion
>> on this thread suggests precisely that we have no real idea how to set
>> these values yet, so more configurability is good. Even if you reject
>> that argument, I think it's a bad idea to start making xmax vacuuming
>> and xmin vacuuming less than parallel; such decisions confuse users.
>
> Yeah, I can relate to this argument. I have added per-table
> configurability to this, and also added the an equivalent of
> autovacuum_freeze_max_age to force a for-wraparound full scan of a table
> based on multixacts.
>
> I haven't really tested this beyond ensuring that it compiles, and I
> haven't changed the default values, but here it is in case someone wants
> to have a look and comment --- particularly on the doc additions.

Using Multixact capitalized just so seems odd to me. Probably should
be lower case (multiple places). This part needs some copy-editing:

+ <para>
+ Vacuum also allows removal of old files from the
+ <filename>pg_multixact/members</> and <filename>pg_multixact/offsets</>
+ subdirectories, which is why the default is a relatively low
+ 50 million transactions.

Vacuuming multixacts also allows...? And: 50 million multixacts, not
transactions.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company