database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-23 03:21:12 +03:00
Code Activity

Clean up a couple of ad-hoc computations of the maximum number of tuples

Browse Source 
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.
This commit is contained in:
Tom Lane
2005-09-02 19:02:20 +00:00
parent 962a4bb69f
commit 35e9b1cc1e
6 changed files with 25 additions and 18 deletions
src
backend
access
gist
gistvacuum.c
nbtree
nbtree.c
commands
vacuum.cvacuumlazy.c
nodes
tidbitmap.c
include
access
htup.h

4
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