Re: workaround steps for autovaccum problem - Mailing list pgsql-general

From Scott Marlowe
Subject Re: workaround steps for autovaccum problem
Date
Msg-id AANLkTinW_KMg9g5D8Cfs_09Ztb9gseqZFTAEuE6TMFVO@mail.gmail.com
Whole thread Raw
In response to Re: workaround steps for autovaccum problem  ("tamanna madaan" <tamanna.madan@globallogic.com>)
Responses Re: workaround steps for autovaccum problem  ("tamanna madaan" <tamanna.madan@globallogic.com>)
List 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 by date:

Previous
From: Michael Hull
Date:
Subject: Search then Delete Performance
Next
From: Arjen Nienhuis
Date:
Subject: Re: Search then Delete Performance