Ü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
