Re: PATCH to allow concurrent VACUUMs to not lock each

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: 2006-07-30 18:55:05
Message-ID: 1154285705.2904.27.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Ühel kenal päeval, P, 2006-07-30 kell 14:11, kirjutas Alvaro Herrera:
> Bruce Momjian wrote:
> >
> > Alvaro has just applied a modified version of this patch.
>
> Hannu, I'm curious:
>
> > Hannu Krosing wrote:
>
> > > 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.

> What was idea behind moving vac_update_relstats to a separate
> transaction? I'm wondering if it's still needed, if it further enhances
> the system somehow, or your patch did something differently than what
> was applied.

The part of transactions which actually modified the data (iirc it updates
relpages and reltuples in pg_class) is not safe to ignore by concurrent
vacuum, say a vacuum on pg_class .

When the updating is done in the same trx that marks itself inVacuum,
then these vacuums would be permitted to remove the old versions of
pg_class and then, in case the inVacuum transaction aborts after that we
are left with no valid pg_class row.

The odds of this happening seem really small, but it might still be
possibe.

Or it might have been some other possible scenario. The main thing was,
that vacuum can only ignore transaxtions which do not modify data and as
vac_update_relstats does modify data it can't be run in isVacuum
transaction.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-07-30 19:18:34 Re: PATCH to allow concurrent VACUUMs to not lock each
Previous Message Tom Lane 2006-07-30 18:39:44 Relation locking and relcache load (was Re: Going for "all green" buildfarm results)

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2006-07-30 19:18:34 Re: PATCH to allow concurrent VACUUMs to not lock each
Previous Message Joe Conway 2006-07-30 18:21:36 Re: [PATCHES] 8.2 features?