pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. 7+ messages / 1 participants [nested] [flat]
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ba80489c66cf721da04dc5b230b3592f97f6be4c Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL9_6_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ffbf1746354a44a16d4d525d62226aa65fdb4e69 Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f0f53195b51a10e5093e0070bb24ef1f574ee725 Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/60661bbf2dca0c1e744c948c74bccab98933c45b Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL9_5_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/33a46993f15a1232ccd83ac70f41935bb7313566 Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_11_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/de622e677cfd3b547a47db2ae1957798bb8df480 Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. @ 2021-01-18 23:33 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2021-01-18 23:33 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_10_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5cd94de777e08d6abefbad065ddcc0ffb2b8368e Modified Files -------------- src/backend/executor/execCurrent.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2021-01-18 23:33 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us> 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us> 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us> 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us> 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us> 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us> 2021-01-18 23:33 pgsql: Avoid crash with WHERE CURRENT OF and a custom scan plan. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox