Robert Haas wrote:
> On Wed, Mar 30, 2011 at 10:57 AM, Bruce Momjian <br...@momjian.us> wrote:
> > I think we have three options:
> >
> > ? ? ? ?o ?find if the use of autovacuum_freeze_max_age is safe, or make
> > ? ? ? ? ? it safe
> > ? ? ? ?o ?document that autovacuum_naptime always happens before
> > ? ? ? ? ? autovacuum does anything and set it high
> > ? ? ? ?o ?modify autovacuum to be an enum, with values on/off/disabled
> >
> > I think the last one makes more sense, and is safer if we need to
> > backpatch this. ?Creating a new variable for this would be confusing
> > because it could conflict with the 'autovacuum' setting.
>
> I have to admit the prospect of abuse is slightly frightening to me
> here. I guess we can't be held responsible for users who do dumb
> things, but it might not be too clear to someone what the difference
> is between autovacuum=off and autovacuum=disabled. I don't really
> understand why this is an issue in the first place, though. Surely we
> must be setting the XID counter on the new cluster to match the one on
> the old cluster, and migrating the relfrozenxid and datfrozenxid
> settings, so why does it matter if someone runs vacuum freeze?
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.
--
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
