Alvaro has just applied a modified version of this patch. ---------------------------------------------------------------------------
Hannu Krosing wrote: > On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote: > > Hannu Krosing <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
