Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 3110cd2

Browse files
committed
Update comment on VACUUM FULL.
Manfred Koizar
1 parent b39ce1c commit 3110cd2

File tree

1 file changed

+13
-8
lines changed

1 file changed

+13
-8
lines changed

src/backend/commands/vacuum.c

+13-8
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313
*
1414
*
1515
* IDENTIFICATION
16-
* $PostgreSQL: pgsql/src/backend/commands/vacuum.c,v 1.299 2004/12/31 21:59:42 pgsql Exp $
16+
* $PostgreSQL: pgsql/src/backend/commands/vacuum.c,v 1.300 2005/02/15 03:50:07 momjian Exp $
1717
*
1818
*-------------------------------------------------------------------------
1919
*/
@@ -1703,20 +1703,25 @@ repair_frag(VRelStats *vacrelstats, Relation onerel,
17031703
tuple_len = tuple.t_len = ItemIdGetLength(itemid);
17041704
ItemPointerSet(&(tuple.t_self), blkno, offnum);
17051705

1706-
/*
1706+
/* ---
17071707
* VACUUM FULL has an exclusive lock on the relation. So
17081708
* normally no other transaction can have pending INSERTs or
1709-
* DELETEs in this relation. A tuple is either (a) a tuple in
1710-
* a system catalog, inserted or deleted by a not yet
1711-
* committed transaction or (b) dead (XMIN_INVALID or
1712-
* XMAX_COMMITTED) or (c) inserted by a committed xact
1713-
* (XMIN_COMMITTED) or (d) moved by the currently running
1714-
* VACUUM. In case (a) we wouldn't be in repair_frag() at all.
1709+
* DELETEs in this relation. A tuple is either:
1710+
* (a) a tuple in a system catalog, inserted or deleted
1711+
* by a not yet committed transaction
1712+
* (b) known dead (XMIN_INVALID, or XMAX_COMMITTED and xmax
1713+
* is visible to all active transactions)
1714+
* (c) inserted by a committed xact (XMIN_COMMITTED)
1715+
* (d) moved by the currently running VACUUM.
1716+
* (e) deleted (XMAX_COMMITTED) but at least one active
1717+
* transaction does not see the deleting transaction
1718+
* In case (a) we wouldn't be in repair_frag() at all.
17151719
* In case (b) we cannot be here, because scan_heap() has
17161720
* already marked the item as unused, see continue above. Case
17171721
* (c) is what normally is to be expected. Case (d) is only
17181722
* possible, if a whole tuple chain has been moved while
17191723
* processing this or a higher numbered block.
1724+
* ---
17201725
*/
17211726
if (!(tuple.t_data->t_infomask & HEAP_XMIN_COMMITTED))
17221727
{

0 commit comments

Comments
 (0)