pgsql: Clean up manipulations of hash indexes' hasho_flag field.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Clean up manipulations of hash indexes' hasho_flag field.
Date: 2017-04-14 21:04:32
Message-ID: E1cz8OO-0000LG-Vt@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Clean up manipulations of hash indexes' hasho_flag field.

Standardize on testing a hash index page's type by doing
(opaque->hasho_flag & LH_PAGE_TYPE) == LH_xxx_PAGE
Various places were taking shortcuts like
opaque->hasho_flag & LH_BUCKET_PAGE
which while not actually wrong, is still bad practice because
it encourages use of
opaque->hasho_flag & LH_UNUSED_PAGE
which *is* wrong (LH_UNUSED_PAGE == 0, so the above is constant false).
hash_xlog.c's hash_mask() contained such an incorrect test.

This also ensures that we mask out the additional flag bits that
hasho_flag has accreted since 9.6. pgstattuple's pgstat_hash_page(),
for one, was failing to do that and was thus actively broken.

Also fix assorted comments that hadn't been updated to reflect the
extended usage of hasho_flag, and fix some macros that were testing
just "(hasho_flag & bit)" to use the less dangerous, project-approved
form "((hasho_flag & bit) != 0)".

Coverity found the bug in hash_mask(); I noted the one in
pgstat_hash_page() through code reading.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/2040bb4a0b50ef0434a1a723f00d040ab4f1c06f

Modified Files
--------------
contrib/pageinspect/hashfuncs.c | 12 +++++++-----
contrib/pgstattuple/pgstattuple.c | 2 +-
src/backend/access/hash/hash_xlog.c | 8 +++++---
src/backend/access/hash/hashovfl.c | 2 +-
src/backend/access/hash/hashutil.c | 4 ++--
src/include/access/hash.h | 26 +++++++++++++-------------
6 files changed, 29 insertions(+), 25 deletions(-)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-04-14 21:51:32 pgsql: Use one transaction while reading postgres.bki, not one per line
Previous Message Tom Lane 2017-04-14 18:52:35 pgsql: Further fix pg_trgm's extraction of trigrams from regular expres