Thread: pgsql: Clean up a couple of ad-hoc computations of the maximum number of
pgsql: Clean up a couple of ad-hoc computations of the maximum number of
From
tgl@svr1.postgresql.org (Tom Lane)
Date:
Log Message:
-----------
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.
Modified Files:
--------------
pgsql/src/backend/access/gist:
gistvacuum.c (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistvacuum.c.diff?r1=1.6&r2=1.7)
pgsql/src/backend/access/nbtree:
nbtree.c (r1.130 -> r1.131)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtree.c.diff?r1=1.130&r2=1.131)
pgsql/src/backend/commands:
vacuum.c (r1.313 -> r1.314)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c.diff?r1=1.313&r2=1.314)
vacuumlazy.c (r1.57 -> r1.58)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuumlazy.c.diff?r1=1.57&r2=1.58)
pgsql/src/backend/nodes:
tidbitmap.c (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/nodes/tidbitmap.c.diff?r1=1.6&r2=1.7)
pgsql/src/include/access:
htup.h (r1.76 -> r1.77)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/htup.h.diff?r1=1.76&r2=1.77)