Re: truncating pg_multixact/members

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: truncating pg_multixact/members
Date: 2014-02-12 18:07:33
Message-ID: 20140212180733.GL6342@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

In this new version, I added a couple of fields to VacuumStmt node. How
strongly do we feel this would cause an ABI break? Would we be more
comfortable if I put them at the end of the struct for 9.3 instead?
Do we expect third-party code to be calling vacuum()?

Also, AutoVacOpts (used as part of reloptions) gained three extra
fields. Since this is in the middle of StdRdOptions, it'd be somewhat
more involve to put these at the end of that struct. This might be a
problem if somebody has a module calling RelationIsSecurityView(). If
anyone thinks we should be concerned about such an ABI change, please
shout quickly.

Here is patch v3, which should be final or close to. Changes from
previous:

Robert Haas wrote:

> Using Multixact capitalized just so seems odd to me. Probably should
> be lower case (multiple places).

Changed it to be all lower case. Originally the X was also upper case,
which looked even odder.

> 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.

I reworded this rather completely.

I was missing a change to SetMultiXactIdLimit to use the multixact value
instead of the one for Xids, and passing the values computed by
autovacuum to vacuum().

Per discussion, new default values are 150 million for
vacuum_multixact_freeze_table_age (same as the one for Xids), and 5
million for vacuum_multixact_freeze_min_age. I decided to raise
autovacuum_multixact_freeze_max_age to 400 million, i.e. double the one
for Xids; so there should be no more emergency vacuuming than before
unless multixact consumption is more than double that for Xids. (Now
that I re-read this, the same rationale would have me setting the
default for vacuum_multixact_freeze_table_age to 300 million. Any votes
on that?).

I adjusted the default values everywhere (docs and sample config), and
fixed one or two typos in the docco for Xid vacuuming that I happened to
notice, as well. postgresql.conf.sample contained a couple of
space-before-tab which I removed.

<!-- I thought about using a struct to pass all four values around in
multiple routines rather than 4 ints (vacuum_set_xid_limits,
cluster_rel, rebuild_relation, copy_heap_data). Decided not to for the
time being. Perhaps a patch for HEAD only. -->

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
mxact-freeze-age-3.patch text/x-diff 42.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Atzeri 2014-02-12 18:13:07 Re: narwhal and PGDLLIMPORT
Previous Message Magnus Hagander 2014-02-12 17:47:09 Re: Terminating pg_basebackup background streamer