Re: Is there a way to make VACUUM run completely outside

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is there a way to make VACUUM run completely outside
Date: 2005-02-07 17:16:41
Message-ID: 1107796601.26510.11.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ühel kenal päeval (esmaspäev, 7. veebruar 2005, 10:51-0500), kirjutas
Tom Lane:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > As VACUUM is not something that can be rolled back, could we not make it
> > run completely outside transactions.
>
> No, because it has to be able to hold a table-level lock on the target
> table.

Does NON-FULL VACUUM release this lock when pausing when sleeping on
vacuum_cost_delay ?

If not, could it be made to release the lock and end current transaction
when going to sleep and start a new transaction and aquire the lock
again when waking up ?

> Besides, where did you get the idea that it can't be rolled back?
> The VACUUM FULL case, at least, has to go through huge pushups to be
> sure it is rollback-safe.

What are the semantics of ROLLBACKing a VACUUM FULL ? Will it restore
the dead tuples to their original positions ?

I assumed that it does its data-shuffling behind the scenes so that
changes done by it are invisible to others at the *logical* level.

If all the changes it does to internal data storage can be rolled back,
then I can't see how VACUUM FULL can work at all without requiring 2x
the filesize for the ROLLBACK.

Also, why must it be run outside of transaction block if it can be
rollbacked ?

--
Hannu Krosing <hannu(at)tm(dot)ee>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-02-07 17:28:34 Re: Patent issues and 8.1
Previous Message Bruno Wolff III 2005-02-07 17:15:55 Re: Query optimizer 8.0.1 (and 8.0)