postgres

History

Robert Haas d4b5d4cadd 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 `dab42382f4`, 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.		9 years ago
..
expected	…
sql	…
.gitignore	…
Makefile	Remove superuser checks in pgstattuple	9 years ago
pgstatapprox.c	Remove superuser checks in pgstattuple	9 years ago
pgstatindex.c	Remove superuser checks in pgstattuple	9 years ago
pgstattuple--1.0--1.1.sql	…
pgstattuple--1.1--1.2.sql	…
pgstattuple--1.2--1.3.sql	…
pgstattuple--1.3--1.4.sql	Update pgstattuple extension for parallel query.	10 years ago
pgstattuple--1.4--1.5.sql	Remove superuser checks in pgstattuple	9 years ago
pgstattuple--1.4.sql	Minor fixes in contrib installation scripts.	10 years ago
pgstattuple--unpackaged--1.0.sql	…
pgstattuple.c	pgstattuple: Don't take heavyweight locks when examining a hash index.	9 years ago
pgstattuple.control	Remove superuser checks in pgstattuple	9 years ago