From 35e9b1cc1ee296959d52383455052cb3743af478 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 2 Sep 2005 19:02:20 +0000 Subject: Clean up a couple of ad-hoc computations of the maximum number of tuples on a page, as suggested by ITAGAKI Takahiro. Also, change a few places that were using some other estimates of max-items-per-page to consistently use MaxOffsetNumber. This is conservatively large --- we could have used the new MaxHeapTuplesPerPage macro, or a similar one for index tuples --- but those places are simply declaring a fixed-size buffer and assuming it will work, rather than actively testing for overrun. It seems safer to size these buffers in a way that can't overflow even if the page is corrupt. --- src/backend/nodes/tidbitmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/backend/nodes/tidbitmap.c') diff --git a/src/backend/nodes/tidbitmap.c b/src/backend/nodes/tidbitmap.c index e36a8d9806..a3b5c7d6d0 100644 --- a/src/backend/nodes/tidbitmap.c +++ b/src/backend/nodes/tidbitmap.c @@ -23,7 +23,7 @@ * Copyright (c) 2003-2005, PostgreSQL Global Development Group * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/nodes/tidbitmap.c,v 1.6 2005/08/28 22:47:20 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/nodes/tidbitmap.c,v 1.7 2005/09/02 19:02:20 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -42,7 +42,7 @@ * the per-page bitmaps variable size. We just legislate that the size * is this: */ -#define MAX_TUPLES_PER_PAGE ((BLCKSZ - 1) / MAXALIGN(offsetof(HeapTupleHeaderData, t_bits) + sizeof(ItemIdData)) + 1) +#define MAX_TUPLES_PER_PAGE MaxHeapTuplesPerPage /* * When we have to switch over to lossy storage, we use a data structure -- cgit v1.2.1