Re: Refactoring - Mailing list pgsql-hackers
| From | Bruce Momjian |
|---|---|
| Subject | Re: Refactoring |
| Date | |
| Msg-id | 200502150349.j1F3new04362@candle.pha.pa.us Whole thread Raw |
| In response to | Re: Refactoring (Manfred Koizar <mkoi-pg@aon.at>) |
| List | 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 by date: