aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvalidate.c
diff options
context:
space:
mode:
authorThomas Munro <tmunro@postgresql.org>2019-08-28 13:37:03 +1200
committerThomas Munro <tmunro@postgresql.org>2019-08-28 17:59:27 +1200
commitb9c4ccfefca00dc42db9761a8b6f930a040c82c9 (patch)
treed37b7f2644094e52f78b6ea9bec3f50a5f70bffe /src/backend/access/gist/gistvalidate.c
parentf51006ea9657d6fcad89298520f42071fcf2199e (diff)
downloadpostgresql-b9c4ccfefca00dc42db9761a8b6f930a040c82c9.tar.gz
postgresql-b9c4ccfefca00dc42db9761a8b6f930a040c82c9.zip
Avoid catalog lookups in RelationAllowsEarlyPruning().
RelationAllowsEarlyPruning() performed a catalog scan, but is used in two contexts where that was a bad idea: 1. In heap_page_prune_opt(), which runs very frequently in some large scans. This caused major performance problems in a field report that was easy to reproduce. 2. In TestForOldSnapshot(), which runs while we hold a buffer content lock. It's not clear if this was guaranteed to be free of buffer deadlock risk. The check was introduced in commit 2cc41acd8 and defended against a real problem: 9.6's hash indexes have no page LSN and so we can't allow early pruning (ie the snapshot-too-old feature). We can remove the check from all later releases though: hash indexes are now logged, and there is no way to create UNLOGGED indexes on regular logged tables. If a future release allows such a combination, it might need to put a similar check in place, but it'll need some more thought. Back-patch to 10. Author: Thomas Munro Reviewed-by: Tom Lane, who spotted the second problem Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions