pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix possible crash during WindowAgg evaluation 4+ messages / 1 participants [nested] [flat]
* pgsql: Fix possible crash during WindowAgg evaluation @ 2024-12-09 01:23 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: David Rowley @ 2024-12-09 01:23 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix possible crash during WindowAgg evaluation When short-circuiting WindowAgg node evaluation on the top-level WindowAgg node using quals on monotonic window functions, because the WindowAgg run condition can mean there's no need to evaluate subsequent window function results in the same partition once the run condition becomes false, it was possible that the executor would use stale results from the previous invocation of the window function in some cases. A fix for this was partially done by a5832722, but that commit only fixed the issue for non-top-level WindowAgg nodes. I mistakenly thought that the top-level WindowAgg didn't have this issue, but Jayesh's example case clearly shows that's incorrect. At the time, I also thought that this only affected 32-bit systems as all window functions which then supported run conditions returned BIGINT, however, that's wrong as ExecProject is still called and that could cause evaluation of any other window function belonging to the same WindowAgg node, one of which may return a byref type. The only queries affected by this are WindowAggs with a "Run Condition" which contains at least one window function with a byref result type, such as lead() or lag() on a byref column. The window clause must also contain a PARTITION BY clause (without a PARTITION BY, execution of the WindowAgg stops immediately when the run condition becomes false and there's no risk of using the stale results). Reported-by: Jayesh Dehankar Discussion: https://postgr.es/m/193261e2c4d.3dd3cd7c1842.871636075166132237@zohocorp.com Backpatch-through: 15, where WindowAgg run conditions were added Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/1fe5a347e36f9f5f288b3574597d4e279fc72a65 Modified Files -------------- src/backend/executor/nodeWindowAgg.c | 35 +++++++++++++++++------------------ src/test/regress/expected/window.out | 10 ++++++++++ src/test/regress/sql/window.sql | 7 +++++++ 3 files changed, 34 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix possible crash during WindowAgg evaluation @ 2024-12-09 01:24 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: David Rowley @ 2024-12-09 01:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix possible crash during WindowAgg evaluation When short-circuiting WindowAgg node evaluation on the top-level WindowAgg node using quals on monotonic window functions, because the WindowAgg run condition can mean there's no need to evaluate subsequent window function results in the same partition once the run condition becomes false, it was possible that the executor would use stale results from the previous invocation of the window function in some cases. A fix for this was partially done by a5832722, but that commit only fixed the issue for non-top-level WindowAgg nodes. I mistakenly thought that the top-level WindowAgg didn't have this issue, but Jayesh's example case clearly shows that's incorrect. At the time, I also thought that this only affected 32-bit systems as all window functions which then supported run conditions returned BIGINT, however, that's wrong as ExecProject is still called and that could cause evaluation of any other window function belonging to the same WindowAgg node, one of which may return a byref type. The only queries affected by this are WindowAggs with a "Run Condition" which contains at least one window function with a byref result type, such as lead() or lag() on a byref column. The window clause must also contain a PARTITION BY clause (without a PARTITION BY, execution of the WindowAgg stops immediately when the run condition becomes false and there's no risk of using the stale results). Reported-by: Jayesh Dehankar Discussion: https://postgr.es/m/193261e2c4d.3dd3cd7c1842.871636075166132237@zohocorp.com Backpatch-through: 15, where WindowAgg run conditions were added Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9d5ce4f1a00aae95193b9737c4e8ced7f0aa4aaa Modified Files -------------- src/backend/executor/nodeWindowAgg.c | 35 +++++++++++++++++------------------ src/test/regress/expected/window.out | 10 ++++++++++ src/test/regress/sql/window.sql | 7 +++++++ 3 files changed, 34 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix possible crash during WindowAgg evaluation @ 2024-12-09 01:24 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: David Rowley @ 2024-12-09 01:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix possible crash during WindowAgg evaluation When short-circuiting WindowAgg node evaluation on the top-level WindowAgg node using quals on monotonic window functions, because the WindowAgg run condition can mean there's no need to evaluate subsequent window function results in the same partition once the run condition becomes false, it was possible that the executor would use stale results from the previous invocation of the window function in some cases. A fix for this was partially done by a5832722, but that commit only fixed the issue for non-top-level WindowAgg nodes. I mistakenly thought that the top-level WindowAgg didn't have this issue, but Jayesh's example case clearly shows that's incorrect. At the time, I also thought that this only affected 32-bit systems as all window functions which then supported run conditions returned BIGINT, however, that's wrong as ExecProject is still called and that could cause evaluation of any other window function belonging to the same WindowAgg node, one of which may return a byref type. The only queries affected by this are WindowAggs with a "Run Condition" which contains at least one window function with a byref result type, such as lead() or lag() on a byref column. The window clause must also contain a PARTITION BY clause (without a PARTITION BY, execution of the WindowAgg stops immediately when the run condition becomes false and there's no risk of using the stale results). Reported-by: Jayesh Dehankar Discussion: https://postgr.es/m/193261e2c4d.3dd3cd7c1842.871636075166132237@zohocorp.com Backpatch-through: 15, where WindowAgg run conditions were added Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c1d6506acc2b0b8c0aa1209ce5187b20caee205e Modified Files -------------- src/backend/executor/nodeWindowAgg.c | 35 +++++++++++++++++------------------ src/test/regress/expected/window.out | 10 ++++++++++ src/test/regress/sql/window.sql | 7 +++++++ 3 files changed, 34 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix possible crash during WindowAgg evaluation @ 2024-12-09 01:25 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: David Rowley @ 2024-12-09 01:25 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix possible crash during WindowAgg evaluation When short-circuiting WindowAgg node evaluation on the top-level WindowAgg node using quals on monotonic window functions, because the WindowAgg run condition can mean there's no need to evaluate subsequent window function results in the same partition once the run condition becomes false, it was possible that the executor would use stale results from the previous invocation of the window function in some cases. A fix for this was partially done by a5832722, but that commit only fixed the issue for non-top-level WindowAgg nodes. I mistakenly thought that the top-level WindowAgg didn't have this issue, but Jayesh's example case clearly shows that's incorrect. At the time, I also thought that this only affected 32-bit systems as all window functions which then supported run conditions returned BIGINT, however, that's wrong as ExecProject is still called and that could cause evaluation of any other window function belonging to the same WindowAgg node, one of which may return a byref type. The only queries affected by this are WindowAggs with a "Run Condition" which contains at least one window function with a byref result type, such as lead() or lag() on a byref column. The window clause must also contain a PARTITION BY clause (without a PARTITION BY, execution of the WindowAgg stops immediately when the run condition becomes false and there's no risk of using the stale results). Reported-by: Jayesh Dehankar Discussion: https://postgr.es/m/193261e2c4d.3dd3cd7c1842.871636075166132237@zohocorp.com Backpatch-through: 15, where WindowAgg run conditions were added Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d54378e984d72914abc1dd84898f494ba2168c27 Modified Files -------------- src/backend/executor/nodeWindowAgg.c | 35 +++++++++++++++++------------------ src/test/regress/expected/window.out | 10 ++++++++++ src/test/regress/sql/window.sql | 7 +++++++ 3 files changed, 34 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-12-09 01:25 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-12-09 01:23 pgsql: Fix possible crash during WindowAgg evaluation David Rowley <drowley@postgresql.org> 2024-12-09 01:24 pgsql: Fix possible crash during WindowAgg evaluation David Rowley <drowley@postgresql.org> 2024-12-09 01:24 pgsql: Fix possible crash during WindowAgg evaluation David Rowley <drowley@postgresql.org> 2024-12-09 01:25 pgsql: Fix possible crash during WindowAgg evaluation David Rowley <drowley@postgresql.org>
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