From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: PATCH to allow concurrent VACUUMs to not lock each |
Date: | 2005-07-03 16:14:38 |
Message-ID: | 1120407279.17231.1.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)skype(dot)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(at)skype(dot)net>
Attachment | Content-Type | Size |
---|---|---|
vacuum-patch-8_1.diff | text/x-patch | 7.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-03 16:19:49 | Re: PATCH to allow concurrent VACUUMs to not lock each |
Previous Message | Tom Lane | 2005-07-03 16:10:28 | Re: [HACKERS] Dbsize backend integration |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-03 16:19:49 | Re: PATCH to allow concurrent VACUUMs to not lock each |
Previous Message | Tom Lane | 2005-07-03 16:10:28 | Re: [HACKERS] Dbsize backend integration |