From: | Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuumdb --freeze |
Date: | 2009-02-19 17:11:56 |
Message-ID: | 6DAFE8F5425AB84DB3FCA4537D829A561CF6629ED0@M0164.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > One more question I have though is:
> > How do you make sure noone (e.g. autovacuum analyze)
> > unfreezes tuples after the vacuum freeze ?
>
> I will start a new thread to answer this question, but the short answer
> is that the freeze only needs to happen in a fresh initdb database, and
> once clog is copied over, new transactions can be created normally.
Yes.
I am still answering here because my question was related to upgrade.
I think you need to turn off autovacuum before freezing to avoid a later analyze
that unfreezes pg_class (or the stats table).
Also to really have all tables frozen I think the order of the freezes is crutial.
Consider the order:
freeze pg_class
freeze pg_columns --> won't this unfreeze pg_class ?
And what about shared catalogs ?
Or does heap_update not change the xid ? Or can it use a frozen xid ?
Or does it all work when done in one large transaction ?
I think I am confused, sorry :-(
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-19 17:24:36 | Re: vacuumdb --freeze |
Previous Message | Lawrence, Ramon | 2009-02-19 16:37:05 | Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets |