aboutsummaryrefslogtreecommitdiff
path: root/src/include/access/heapam.h
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2011-11-07 21:39:40 -0500
committerRobert Haas <rhaas@postgresql.org>2011-11-07 21:39:40 -0500
commitbbb6e559c4ea0fb4c346beda76736451dc24eb4e (patch)
treea49de5afba6376d371afaf3e78bcc1a117a6f37f /src/include/access/heapam.h
parentbd2396988a1afbcb6424700e52a62f34d2951bdd (diff)
downloadpostgresql-bbb6e559c4ea0fb4c346beda76736451dc24eb4e.tar.gz
postgresql-bbb6e559c4ea0fb4c346beda76736451dc24eb4e.zip
Make VACUUM avoid waiting for a cleanup lock, where possible.
In a regular VACUUM, it's OK to skip pages for which a cleanup lock isn't immediately available; the next VACUUM will deal with them. If we're scanning the entire relation to advance relfrozenxid, we might need to wait, but only if there are tuples on the page that actually require freezing. These changes should greatly reduce the incidence of of vacuum processes getting "stuck". Simon Riggs and Robert Haas
Diffstat (limited to 'src/include/access/heapam.h')
-rw-r--r--src/include/access/heapam.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index 776ea5c4cc5..85cbeb3273b 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -111,6 +111,8 @@ extern HTSU_Result heap_lock_tuple(Relation relation, HeapTuple tuple,
extern void heap_inplace_update(Relation relation, HeapTuple tuple);
extern bool heap_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid,
Buffer buf);
+extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
+ Buffer buf);
extern Oid simple_heap_insert(Relation relation, HeapTuple tup);
extern void simple_heap_delete(Relation relation, ItemPointer tid);