Re: workaround steps for autovaccum problem

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: workaround steps for autovaccum problem
Дата
Msg-id AANLkTinW_KMg9g5D8Cfs_09Ztb9gseqZFTAEuE6TMFVO@mail.gmail.com
обсуждение исходный текст
Ответ на Re: workaround steps for autovaccum problem  ("tamanna madaan" <tamanna.madan@globallogic.com>)
Ответы Re: workaround steps for autovaccum problem  ("tamanna madaan" <tamanna.madan@globallogic.com>)
Список pgsql-general
On Tue, Sep 14, 2010 at 6:00 PM, tamanna madaan
<tamanna.madan@globallogic.com> wrote:
> I know upgrading postgres will resolve the problem permanently .
> But I wanted some workaround for now before I actually upgrade.
> But let me know if I really need to execute `vacuum freeze`
> In the scenario given in my previous update  or I can skip this step.
>
> For your reference I am again updating the scenario :
>
> Autovacuum is getting invoked after every 5 mins and vacuums all the
> database turn by turn and every database is getting its turn of
> autovaccum after every 20 mins as there are 4 databases (template0 ,
> template1, postgres and abc(my database) ).
>
>
> Now suppose , this autovacuum problem occurs and through some script its
> detected immediately at the very onset of the problem and below
> mentioned workaround steps are executed
>
> 1. Stop postgres
> 2. create 256K zero filled  0C01 file in /var/lib/pgsql/data/pg_clog
> folder.
> 3. Start postgres
>
> Then still , do I need to execute 'vacuum freeze' on all databases ??

Vacuum freeze is primarily intended for template databases that never
get updated.  If you have to allow conn to template0 to copy it, then
yes maybe.

This whole exercise smacks of doing more work to avoid upgrading than
how much work the upgrade will be.

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

Предыдущее
От: Michael Hull
Дата:
Сообщение: Search then Delete Performance
Следующее
От: Arjen Nienhuis
Дата:
Сообщение: Re: Search then Delete Performance