Re: PATCH to allow concurrent VACUUMs to not lock each - Mailing list pgsql-patches

From Hannu Krosing
Subject Re: PATCH to allow concurrent VACUUMs to not lock each
Date
Msg-id 1120407279.17231.1.camel@fuji.krosing.net
Whole thread Raw
In response to Re: PATCH to allow concurrent VACUUMs to not lock each  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PATCH to allow concurrent VACUUMs to not lock each  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PATCH to allow concurrent VACUUMs to not lock each  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@skype.net> writes:
> > I can't think of any other cases where it could matter, as at least the
> > work done inside vacuum_rel() itself seema non-rollbackable.
>
> VACUUM FULL's tuple-moving is definitely roll-back-able, so it might be
> prudent to only do this for lazy VACUUM.  But on the other hand, VACUUM
> FULL holds an exclusive lock on the table so no one else is going to see
> its effects concurrently anyway.

Ok, this is a new version of the vacuum patch with the following changes
following some suggestions in this thread.

* changed the patch to affect only lazy vacuum
* moved inVacuum handling to use PG_TRY
* moved vac_update_relstats() out of lazy_vacuum_rel into a separate
  transaction. The code to do this may not be the prettiest, maybe it
  should use a separate struct.

--
Hannu Krosing <hannu@skype.net>

Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Dbsize backend integration
Next
From: Tom Lane
Date:
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each