| commit | 5beb7881fb27d1830fa4c57ba263c8042449a599 | |
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Thu, 22 Dec 2022 15:35:02 +0000 (22 10:35 -0500) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Thu, 22 Dec 2022 15:35:02 +0000 (22 10:35 -0500) | ||
| tree | 9dd24b5565048c8d2201af195f49bec1a5111165 | treesnapshot (tar.gz zip) |
| parent | 73bb72f0ca2833329b59ebaf9476be3be71e462f | commitdiff |
Add some recursion and looping defenses in prepjointree.c.
Andrey Lepikhov demonstrated a case where we spend an unreasonable
amount of time in pull_up_subqueries(). Not only is that recursing
with no explicit check for stack overrun, but the code seems not
interruptable by control-C. Let's stick a CHECK_FOR_INTERRUPTS
there, along with sprinkling some stack depth checks.
An actual fix for the excessive time consumption seems a bit
risky to back-patch; but this isn't, so let's do so.
Discussion: https://postgr.es/m/703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru
Andrey Lepikhov demonstrated a case where we spend an unreasonable
amount of time in pull_up_subqueries(). Not only is that recursing
with no explicit check for stack overrun, but the code seems not
interruptable by control-C. Let's stick a CHECK_FOR_INTERRUPTS
there, along with sprinkling some stack depth checks.
An actual fix for the excessive time consumption seems a bit
risky to back-patch; but this isn't, so let's do so.
Discussion: https://postgr.es/m/703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru
| src/backend/optimizer/prep/prepjointree.c | diffblobblamehistory |