pgsql: pgstattuple: Don't take heavyweight locks when examining a hash - Mailing list pgsql-committers

From Robert Haas
Subject pgsql: pgstattuple: Don't take heavyweight locks when examining a hash
Date
Msg-id E1c09xN-00026Z-67@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
pgstattuple: Don't take heavyweight locks when examining a hash index.

It's currently necessary to take a heavyweight lock when scanning a
hash bucket, but pgstattuple only examines individual pages, so it
doesn't need to do this.  If, for some hypothetical reason, it did
need to do any heavyweight locking here, this logic would probably
still be incorrect, because most of the locks that it is taking are
meaningless.  Only a heavyweight lock on a primary bucket page has any
meaning, but this takes heavyweight locks on all pages regardless of
function - and in particular overflow pages, where you might imagine
that we'd want to lock the primary bucket page if we needed to lock
anything at all.

This is arguably a bug that has existed since this code was added in
commit dab42382f483c3070bdce14a4d93c5d0cf61e82b, but I'm not going to
bother back-patching it because in most cases the only consequence is
that running pgstattuple() on a hash index is a little slower than it
otherwise might be, which is no big deal.

Extracted from a vastly larger patch by Amit Kapila which heavyweight
locking for hash indexes entirely; analysis of why this can be done
independently of the rest by me.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/d4b5d4caddb73f954d9ef86641201dc99677719d

Modified Files
--------------
contrib/pgstattuple/pgstattuple.c | 2 --
1 file changed, 2 deletions(-)


pgsql-committers by date:

Previous
From: Robert Haas
Date:
Subject: pgsql: Fix leftover reference to background writer performing checkpoin
Next
From: Magnus Hagander
Date:
Subject: pgsql: Fix memory leak in tar file padding