Re: vacuumdb --freeze
| От | Zeugswetter Andreas OSB sIT |
|---|---|
| Тема | Re: vacuumdb --freeze |
| Дата | |
| Msg-id | 6DAFE8F5425AB84DB3FCA4537D829A561CF6629ED0@M0164.s-mxs.net обсуждение исходный текст |
| Ответ на | Re: vacuumdb --freeze (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: vacuumdb --freeze
|
| Список | 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
В списке pgsql-hackers по дате отправления: