aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-01-18 18:32:30 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-01-18 18:32:40 -0500
commitf0f53195b51a10e5093e0070bb24ef1f574ee725 (patch)
tree11922d0dc8167bd3bb4b9b7e80e4339b490c9fcd /src/backend/access/gist
parentb8daf894f0d3440dd79131e12221c30b114e4b3e (diff)
downloadpostgresql-f0f53195b51a10e5093e0070bb24ef1f574ee725.tar.gz
postgresql-f0f53195b51a10e5093e0070bb24ef1f574ee725.zip
Avoid crash with WHERE CURRENT OF and a custom scan plan.
execCurrent.c's search_plan_tree() assumed that ForeignScanStates and CustomScanStates necessarily have a valid ss_currentRelation. This is demonstrably untrue for postgres_fdw's remote join and remote aggregation plans, and non-leaf custom scans might not have an identifiable scan relation either. Avoid crashing by ignoring such nodes when the field is null. This solution will lead to errors like 'cursor "foo" is not a simply updatable scan of table "bar"' in cases where maybe we could have allowed WHERE CURRENT OF to work. That's not an issue for postgres_fdw's usages, since joins or aggregations would render WHERE CURRENT OF invalid anyway. But an otherwise-transparent upper level custom scan node might find this annoying. When and if someone cares to expend work on such a scenario, we could invent a custom-scan-provider callback to determine what's safe. Report and patch by David Geier, commentary by me. It's been like this for awhile, so back-patch to all supported branches. Discussion: https://postgr.es/m/0253344d-9bdd-11c4-7f0d-d88c02cd7991@swarm64.com
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions