12 Commits (2071865caaf742a65b9166a9bd4bed3b784d90f0)

Author	SHA1	Message	Date
Bruce Momjian	d82a1d582c	This is the patch replace offnum++ by OffsetNumberNext, to be ... consistent. OffsetNumberNext() has some casting that makes it useful. Fujii Masao	18 years ago
Alvaro Herrera	9084399782	Put back bufmgr.h in bufpage.h -- it is needed by some macros. ... Remove #include bufmgr.h from (most?) source files which already include bufpage.h.	18 years ago
Alvaro Herrera	f8c4d7db60	Restructure some header files a bit, in particular heapam.h, by removing some ... unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.	18 years ago
Alvaro Herrera	73b0300b2a	Move the HTSU_Result enum definition into snapshot.h, to avoid including ... tqual.h into heapam.h. This makes all inclusion of tqual.h explicit. I also sorted alphabetically the includes on some source files.	18 years ago
Tom Lane	3e701a04fe	Fix heap_page_prune's problem with failing to send cache invalidation ... messages if the calling transaction aborts later on. Collapsing out line pointer redirects is a done deal as soon as we complete the page update, so syscache *must* be notified even if the VACUUM FULL as a whole doesn't complete. To fix, add some functionality to inval.c to allow the pending inval messages to be sent immediately while heap_page_prune is still running. The implementation is a bit chintzy: it will only work in the context of VACUUM FULL. But that's all we need now, and it can always be extended later if needed. Per my trouble report of a week ago.	18 years ago
Tom Lane	6f10eb2111	Refactor heap_page_prune so that instead of changing item states on-the-fly, ... it accumulates the set of changes to be made and then applies them. It had to accumulate the set of changes anyway to prepare a WAL record for the pruning action, so this isn't an enormous change; the only new complexity is to not doubly mark tuples that are visited twice in the scan. The main advantage is that we can substantially reduce the scope of the critical section in which the changes are applied, thus avoiding PANIC in foreseeable cases like running out of memory in inval.c. A nice secondary advantage is that it is now far clearer that WAL replay will actually do the same thing that the original pruning did. This commit doesn't do anything about the open problem that CacheInvalidateHeapTuple doesn't have the right semantics for a CTID change caused by collapsing out a redirect pointer. But whatever we do about that, it'll be a good idea to not do it inside a critical section.	18 years ago
Bruce Momjian	9098ab9e32	Update copyrights in source tree to 2008.	18 years ago
Bruce Momjian	f6e8730d11	Re-run pgindent with updated list of typedefs. (Updated README should ... avoid this problem in the future.)	18 years ago
Bruce Momjian	fdf5a5efb7	pgindent run for 8.3.	18 years ago
Tom Lane	9226ba817b	Keep heap_page_prune from marking the buffer dirty when it didn't ... really change anything. Per report from Itagaki Takahiro. Fix by Pavan Deolasee.	18 years ago
Tom Lane	cc59049daf	Improve handling of prune/no-prune decisions by storing a page's oldest ... unpruned XMAX in its header. At the cost of 4 bytes per page, this keeps us from performing heap_page_prune when there's no chance of pruning anything. Seems to be necessary per Heikki's preliminary performance testing.	18 years ago
Tom Lane	282d2a03dd	HOT updates. When we update a tuple without changing any of its indexed ... columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.	18 years ago