Re: Hot Standby and VACUUM FULL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hot Standby and VACUUM FULL
Дата
Msg-id 15381.1264968859@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hot Standby and VACUUM FULL  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Hot Standby and VACUUM FULL  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Hot Standby and VACUUM FULL  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote:
>> Anyway, it's still not apparent to me exactly what the connection is
>> between VACUUM FULL and Hot Standby.  I remember that we said HS didn't
>> work with VACUUM FULL (INPLACE) but I don't recall why that is, and the

[ sorry, I meant not-INPLACE ]

>> links on the open-items pages are not leading me to any useful
>> discussion.

> Very little really; not enough to force the sort of changes that I am
> now seeing will be required in the way catalogs and caches operate.
> There was some difficulty around the fact that VFI issues two commits
> for the same transaction, but that is now correctly handled in the code
> after discussion.

If the only benefit of getting rid of VACUUM FULL were simplifying
Hot Standby, I'd agree with you.  But there are numerous other benefits.
The double-commit hack you mention is something we need to get rid of
for general system stability (because of the risk of PANIC if the vacuum
fails after the first commit).  Getting rid of REINDEX-in-place on
shared catalog indexes is another thing that's really safety critical.
Removing V-F related hacks in other places would just be a bonus.

It's something we need to do, so if Hot Standby is forcing our hands,
then let's just do it.
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Hot Standby and VACUUM FULL