> Why are you doing FULL vacuums? Is there some problem that regular vacuums
aren't solving?
Using dump/restore from a live DB to fresh DB, I get a DB that takes (49M +
12M - {I have two table spaces)) 61M of disk. Maximum size that I can grow by
the quota allocated to DB is 100M.
A regular vacuum doesn't stop the database growth, and DB grows beyond 100M.
Then we have to trigger a script that dump/restores on the live database. For
that we have a small outage (which is right now automated).
A full vacuum keeps the database below 100M and no outage.
> Yes, vacuum full takes a hard lock on a table.
That means Table Level AccessExclusiveLock, right?
-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Sent: Thursday, August 30, 2007 10:29 AM
To: Nitin Verma
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] What kind of locks does vacuum process hold on the db?
On 8/29/07, Nitin Verma <nitinverma@azulsystems.com> wrote:
> What kind of locks does it hold on the db? Table level / Row level /
> AccessExclusiveLock ?
> Is there a document that details vacuum process, and its internals?
>
>
> Use case: I am doing a vacuum {all full analyze} on a postgres 8.1 hosting
> two user databases. For this I am using ${pg-home}/bin/vacuumdb, not direct
> SQLs. Parallel to this I am running transaction on both user-DBs.
> Observation:
> Transactions don't pause while vacuum is running. (Odd, how come?)
Why are you doing FULL vacuums? Is there some problem that regular
vacuums aren't solving?
> After this I tried two vacuums in parallel but those lock each other.
Yes, vacuum full takes a hard lock on a table.
Vacuum full is to be avoided.
