Skip site navigation (1) Skip section navigation (2)

Re: BUG #5774: VACCUM & REINDEX kills production environement

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Bala Murugan <b2m(at)a-cti(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5774: VACCUM & REINDEX kills production environement
Date: 2010-11-28 16:23:31
Message-ID: 20101128162331.GA11758@depesz.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On Sun, Nov 28, 2010 at 07:25:52AM +0000, Bala Murugan wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:      5774
> Logged by:          Bala Murugan
> Email address:      b2m(at)a-cti(dot)com
> PostgreSQL version: 8.3.7
> Operating system:   openSUSE 10.3 (X86-64) - Kernel \r (\l).
> Description:        VACCUM & REINDEX kills production environement
> Details: 
> 
> Iam running postgres 8.3 version for more than 2 yrs on Amazon EC2 Instance,
> in recent days Vaccum and reindex make the application down for more than
> 2hrs. I am not sure this because of my configuration or postgres.

is it normal vacuum?

or are you using "vacuum full"?

generally - voth vacuum full and reindex do lock tables for exclusive
access.

that's why you generally don't use them!

vacuum full is especially frowned upon.

as for reindex - if you *really* need it (are you sure? what makes you
think you need it), then there are ways to do reindex without actually
using "reindex" command, which are mostly transparent for users, but you
should check if you really need to run reindex at all.

Best regards,

depesz

-- 
Linkedin: http://www.linkedin.com/in/depesz  /  blog: http://www.depesz.com/
jid/gtalk: depesz(at)depesz(dot)com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-11-28 16:25:49
Subject: Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
Previous:From: Robert HaasDate: 2010-11-28 13:05:12
Subject: Re: Documentation bug: Chapter 35.4, paragraph 4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group