Re: Refactoring

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Refactoring
Дата
Msg-id 200502150349.j1F3new04362@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Refactoring  (Manfred Koizar <mkoi-pg@aon.at>)
Список pgsql-hackers
Manfred Koizar wrote:
> On Wed, 19 Jan 2005 18:57:48 +0100, I wrote:
> >  My first vacuum.c
> >refactoring patch, rev 1.281 2004-06-08, added these comments in
> >repair_frag():
> >
> >/*
> > * VACUUM FULL has an exclusive lock on the relation.  So
> > * normally no other transaction can have pending INSERTs or
> > * DELETEs in this relation.  A tuple is either
> > *   (a) a tuple in a system catalog, inserted or deleted by
> > *       a not yet committed transaction or
> > *   (b) dead (XMIN_INVALID or XMAX_COMMITTED) or
> > *   (c) inserted by a committed xact (XMIN_COMMITTED) or
> > *   (d) moved by the currently running VACUUM.
> > * In case (a) we wouldn't be in repair_frag() at all.
> > * In case (b) we cannot be here, because scan_heap() has
> > * already marked the item as unused, see continue above.
> > * Case (c) is what normally is to be expected.
> > * Case (d) is only possible, if a whole tuple chain has been
> > * moved while processing this or a higher numbered block.
> > */
> 
> It turns out that this comment is not quite correct.  It is incomplete.
> Case (b) should be: known dead (XMIN_INVALID, or XMAX_COMMITTED and xmax
> is visible to all active transactions).
> 
> And there is a fifth possibility: (e) deleted (XMAX_COMMITTED) but at
> least one active transaction does not see the deleting transaction.
> 
> The patch seems to imply that case (e) is a subcase of (b), but
> effectively tuples in this state are treated more like (c).

OK, comment updated to:
           /* ---            * VACUUM FULL has an exclusive lock on the relation.  So            * normally no other
transactioncan have pending INSERTs or            * DELETEs in this relation.  A tuple is either:            *      (a)
atuple in a system catalog, inserted or deleted            *          by a not yet committed transaction            *
  (b) known dead (XMIN_INVALID, or XMAX_COMMITTED and xmax            *          is visible to all active transactions)
          *      (c) inserted by a committed xact (XMIN_COMMITTED)            *      (d) moved by the currently running
VACUUM.           *      (e) deleted (XMAX_COMMITTED) but at least one active            *          transaction does
notsee the deleting transaction            * In case (a) we wouldn't be in repair_frag() at all.            * In case
(b)we cannot be here, because scan_heap() has            * already marked the item as unused, see continue above. Case
         * (c) is what normally is to be expected. Case (d) is only            * possible, if a whole tuple chain has
beenmoved while            * processing this or a higher numbered block.            * ---            */
 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: 8.0.X and the ARC patent
Следующее
От: Tom Lane
Дата:
Сообщение: Re: enforcing a plan (in brief)