Re: truncating pg_multixact/members

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: truncating pg_multixact/members
Дата
Msg-id 20140212180733.GL6342@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: truncating pg_multixact/members  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: truncating pg_multixact/members  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Terminating pg_basebackup background streamer
Следующее
От: Marco Atzeri
Дата:
Сообщение: Re: narwhal and PGDLLIMPORT