From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Return of the Solaris vacuum polling problem -- anyone remember this? |
Date: | 2010-08-23 19:19:54 |
Message-ID: | 1282590106-sup-7578@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Bruce Momjian's message of lun ago 23 14:55:55 -0400 2010:
> OK, I have attached a proposed patch to improve this. I moved the
> pg_clog mention to a new paragraph and linked it to the reason the
> default is relatively low.
>
> Comments?
I think the new para doesn't make much sense, in context. Why does it
say "freeze"? How can we expect users to understand how that is
related to this parameter?
> --- 4150,4165 ----
> <para>
> Specifies the maximum age (in transactions) that a table's
> <structname>pg_class</>.<structfield>relfrozenxid</> field can
> ! attain before a <command>VACUUM</> freeze operation is forced
> ! to prevent transaction ID wraparound within the table.
> ! Note that the system will launch autovacuum processes to
> ! prevent wraparound even when autovacuum is otherwise disabled.
> ! </para>
> !
> ! <para>
> ! Vacuum freeze also allows removal of old files from the
> ! <filename>pg_clog</> subdirectory, which is why the default
> ! is a relatively low 200 million transactions.
> This parameter can only be set at server start, but the setting
> can be reduced for individual tables by
> changing storage parameters.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-08-23 19:20:15 | Re: WIP: extensible enums |
Previous Message | Peter Eisentraut | 2010-08-23 19:16:42 | Re: [9.1] pg_stat_get_backend_server_addr |