Tom Lane wrote:
> Bruce Momjian <> 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
> > 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);
        test=> insert into test values (1);
        INSERT 0 1
        test=> begin;
        test=> lock table test;
        LOCK TABLE
        test=> vacuum full;
        ERROR:  VACUUM cannot run inside a transaction block

  Bruce Momjian                        |               |  (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

Reply via email to