Bruce Momjian wrote:
> First, I am not sure it is a problem, but based on the IRC reports I
> felt I should ask here for confirmation. Here is a sample pg_dump
> output:
>
> CREATE TABLE sample (
> x integer
> );
>
> -- For binary upgrade, set relfrozenxid.
> UPDATE pg_catalog.pg_class
> SET relfrozenxid = '703'
> WHERE oid = 'sample'::pg_catalog.regclass;
>
> So, we set the cluster xid while we do this schema-only restore. I
> belive it might be possible for autovacuum to run while the schema is
> restored, see an empty table, and set the relfrozenxid to be the current
> xid, when in fact we are about to put a heap file in place of the
> current empty file. I thought the autovacuum_freeze_max_age=2000000000
> would prevent this but now I am not sure. I assumed that since the gap
> between the restored relfrozenxid and the current counter would
> certainly be < 2000000000 that autovacuum would not touch it. It is
> possible these users had drastically modified autovacuum_freeze_max_age
> to cause 3-billion gaps --- again, I have no direct contact with the
> reporters, but I figured being paranoid is a good thing where pg_upgrade
> is involved.
>
> I wonder if the fact that these people never reported the bug means
> there were doing something odd with their servers.
I just updated the C comment about what we are doing:
* Using autovacuum=off disables cleanup vacuum and analyze, but
* freeze vacuums can still happen, so we set
* autovacuum_freeze_max_age very high. We assume all datfrozenxid and
* relfrozen values are less than a gap of 2000000000 from the current
* xid counter, so autovacuum will not touch them.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
