diff options
author | Thomas Munro <tmunro@postgresql.org> | 2019-08-28 13:37:03 +1200 |
---|---|---|
committer | Thomas Munro <tmunro@postgresql.org> | 2019-08-28 16:18:39 +1200 |
commit | 8cc6016a8cd43f84998f57e277a988be651e2e6d (patch) | |
tree | 9f6a90bf48d613665352fbcf38426bb3538aa920 /src/backend/access/gist/gist.c | |
parent | e96f524433dbc562d708c4d09d8455b6bc953613 (diff) | |
download | postgresql-8cc6016a8cd43f84998f57e277a988be651e2e6d.tar.gz postgresql-8cc6016a8cd43f84998f57e277a988be651e2e6d.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/gist.c')
0 files changed, 0 insertions, 0 deletions