Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Дата
Msg-id 14074.1265920352@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> I understand that the final process to switch from one release to
> another needs to be quick. Before that we can have any number of
> preparatory steps. One of those is backup, if you're sane. Another one
> should be a preparatory step that can be performed while the database is
> still on-line that checks that everything is in a good state for
> upgrade. No corruptions, no weird flags, everything good.

No, that's just fantasy.  Unless you lock down the database to read only
(which subverts the point, namely minimal operational downtime), the
prescan doesn't work because it can't be sure somebody didn't break
something after it examined it.  In the case at hand, there's no way to
prevent somebody from running a VACUUM FULL just before you trigger
the changeover.

It would probably be useful to have a utility that runs *in 9.0* and
gets rid of MOVED bits, so that we could drop support for them in 9.1.
But it's not happening for 9.0.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: psql tab completion for DO blocks
Следующее
От: Robert Haas
Дата:
Сообщение: Re: review: More frame options in window functions