Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I'm not sure if autovacuum could be taught to do that --- it could
> >> perhaps launch a vacuum as soon as it notices a large fraction of the
> >> table got deleted, but do we really want to authorize it to launch
> >> VACUUM FULL?
>
> > One problem with VACUUM FULL would be autovacuum waiting for an
> > exclusive lock on the table. Anyway, it is documented now as a possible
> > issue.
>
> I don't care too much about autovacuum waiting awhile to get a lock.
> I do care about other processes getting queued up behind it, though.
>
> Perhaps it would be possible to alter the normal lock queuing semantics
> for this case, so that autovacuum's request doesn't block later
> arrivals, and it can only get the lock when no one is interested in the
> table. Of course, that might never happen, or by the time it does
> there's no point in VACUUM FULL anymore :-(
Can we issue a LOCK TABLE with a statement_timeout, and only do the
VACUUM FULL if we can get a lock quickly? That seems like a plan.
The only problem is that you can't VACUUM FULL in a transaction:
test=> create table test (x int);
CREATE TABLE
test=> insert into test values (1);
INSERT 0 1
test=> begin;
BEGIN
test=> lock table test;
LOCK TABLE
test=> vacuum full;
ERROR: VACUUM cannot run inside a transaction block
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
