agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix missed checks for hashability of container-type equality. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix missed checks for hashability of container-type equality. @ 2026-06-08 15:49 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-06-08 15:49 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed checks for hashability of container-type equality. The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 647889667). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/06e94eccfd910225a78f3510700bc89c1d88782f Modified Files -------------- src/backend/optimizer/plan/subselect.c | 4 +- src/backend/optimizer/util/clauses.c | 9 ++-- src/backend/utils/adt/selfuncs.c | 4 +- src/backend/utils/cache/lsyscache.c | 85 ++++++++++++++++++++++++++++++++-- src/backend/utils/cache/typcache.c | 25 ++++------ src/include/catalog/pg_operator.dat | 4 +- src/include/utils/lsyscache.h | 2 + 7 files changed, 105 insertions(+), 28 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed checks for hashability of container-type equality. @ 2026-06-08 15:49 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-06-08 15:49 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed checks for hashability of container-type equality. The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 647889667). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/11aed8d19cd71d2754ac10c71ec668280bd955f5 Modified Files -------------- src/backend/optimizer/plan/subselect.c | 4 +- src/backend/optimizer/util/clauses.c | 9 ++-- src/backend/utils/cache/lsyscache.c | 85 ++++++++++++++++++++++++++++++++-- src/backend/utils/cache/typcache.c | 25 ++++------ src/include/catalog/pg_operator.dat | 4 +- src/include/utils/lsyscache.h | 2 + 6 files changed, 102 insertions(+), 27 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed checks for hashability of container-type equality. @ 2026-06-08 15:49 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-06-08 15:49 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed checks for hashability of container-type equality. The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 647889667). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/19152e3c29abc09a17f3c6252fe19f59449e827f Modified Files -------------- src/backend/optimizer/plan/subselect.c | 4 +- src/backend/optimizer/util/clauses.c | 9 ++-- src/backend/utils/cache/lsyscache.c | 85 ++++++++++++++++++++++++++++++++-- src/backend/utils/cache/typcache.c | 25 ++++------ src/include/catalog/pg_operator.dat | 4 +- src/include/utils/lsyscache.h | 2 + 6 files changed, 102 insertions(+), 27 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed checks for hashability of container-type equality. @ 2026-06-08 15:49 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-06-08 15:49 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed checks for hashability of container-type equality. The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 647889667). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cf2bfe07364fc7599952b816ee1b07f221422598 Modified Files -------------- src/backend/optimizer/plan/subselect.c | 4 +- src/backend/optimizer/util/clauses.c | 9 ++-- src/backend/utils/cache/lsyscache.c | 85 ++++++++++++++++++++++++++++++++-- src/backend/utils/cache/typcache.c | 25 ++++------ src/include/catalog/pg_operator.dat | 4 +- src/include/utils/lsyscache.h | 2 + 6 files changed, 102 insertions(+), 27 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed checks for hashability of container-type equality. @ 2026-06-08 15:49 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-06-08 15:49 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed checks for hashability of container-type equality. The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 647889667). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/caebac5f16f97e258da07e1fb0d3dfcb56ecce8f Modified Files -------------- src/backend/optimizer/plan/subselect.c | 4 +- src/backend/optimizer/util/clauses.c | 9 ++-- src/backend/utils/cache/lsyscache.c | 85 ++++++++++++++++++++++++++++++++-- src/backend/utils/cache/typcache.c | 25 ++++------ src/include/catalog/pg_operator.dat | 4 +- src/include/utils/lsyscache.h | 2 + 6 files changed, 102 insertions(+), 27 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed checks for hashability of container-type equality. @ 2026-06-08 15:49 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-06-08 15:49 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed checks for hashability of container-type equality. The operators for array_eq, record_eq, range_eq, and multirange_eq are all marked oprcanhash, but there's a pitfall: their hash functions can fail at runtime if the contained type(s) are not hashable. Therefore, the planner has to check hashability of the contained types before deciding it can use hashing in these cases. Not every place had gotten this memo, and noplace at all had considered the issue for ranges or multiranges. In particular we could attempt to use hashing for a ScalarArrayOpExpr on a container type when it won't actually work, leading to "could not identify a hash function ..." runtime failures. For the most part we should fix this in the lookup functions provided by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable. But there's a problem: get_op_hash_functions is not passed the input data type it would need to check. We mustn't change the API of that exported function in a back-patched fix, and even if we wanted to, its call sites in the executor mostly don't have easy access to the required data type OID. Fortunately, the executor call sites don't actually need fixing, because it's expected that the planner verified hashability before building a plan that requires it. Therefore, leave get_op_hash_functions as-is and invent a wrapper function get_op_hash_functions_ext that does the additional checking needed in the planner's uses. We also need to fix hash_ok_operator (extending the fix in 647889667). While at it, neaten up a couple of places in lookup_type_cache where relevant code for multirange cases was written differently from the code for other container types. Note: while this touches pg_operator.dat, it's only to add oid_symbol macros. So there's no on-disk data change and no need for a catversion bump. Reported-by: Andrei Lepikhov <lepihov@gmail.com> Author: Andrei Lepikhov <lepihov@gmail.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/64778fac724ac4e70473937f2d94d397af5a2785 Modified Files -------------- src/backend/optimizer/plan/subselect.c | 4 +- src/backend/optimizer/util/clauses.c | 6 ++- src/backend/utils/cache/lsyscache.c | 85 ++++++++++++++++++++++++++++++++-- src/backend/utils/cache/typcache.c | 25 ++++------ src/include/catalog/pg_operator.dat | 4 +- src/include/utils/lsyscache.h | 2 + 6 files changed, 100 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-06-08 15:49 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-08 15:49 pgsql: Fix missed checks for hashability of container-type equality. Tom Lane <tgl@sss.pgh.pa.us> 2026-06-08 15:49 pgsql: Fix missed checks for hashability of container-type equality. Tom Lane <tgl@sss.pgh.pa.us> 2026-06-08 15:49 pgsql: Fix missed checks for hashability of container-type equality. Tom Lane <tgl@sss.pgh.pa.us> 2026-06-08 15:49 pgsql: Fix missed checks for hashability of container-type equality. Tom Lane <tgl@sss.pgh.pa.us> 2026-06-08 15:49 pgsql: Fix missed checks for hashability of container-type equality. Tom Lane <tgl@sss.pgh.pa.us> 2026-06-08 15:49 pgsql: Fix missed checks for hashability of container-type equality. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox