pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix NULLIF()'s handling of read-write expanded objects. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix NULLIF()'s handling of read-write expanded objects. @ 2024-11-25 23:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-25 23:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix NULLIF()'s handling of read-write expanded objects. If passed a read-write expanded object pointer, the EEOP_NULLIF code would hand that same pointer to the equality function and then (unless equality was reported) also return the same pointer as its value. This is no good, because a function that receives a read-write expanded object pointer is fully entitled to scribble on or even delete the object, thus corrupting the NULLIF output. (This problem is likely unobservable with the equality functions provided in core Postgres, but it's easy to demonstrate with one coded in plpgsql.) To fix, make sure the pointer passed to the equality function is read-only. We can still return the original read-write pointer as the NULLIF result, allowing optimization of later operations. Per bug #18722 from Alexander Lakhin. This has been wrong since we invented expanded objects, so back-patch to all supported branches. Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5b8728cd7f9d3d93b6ff9b48887084fdf0a46e4f Modified Files -------------- src/backend/executor/execExpr.c | 8 ++++++++ src/backend/executor/execExprInterp.c | 14 +++++++++++++- src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++---- src/include/executor/execExpr.h | 1 + src/test/regress/expected/case.out | 8 ++++++++ src/test/regress/sql/case.sql | 5 +++++ 6 files changed, 64 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix NULLIF()'s handling of read-write expanded objects. @ 2024-11-25 23:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-25 23:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix NULLIF()'s handling of read-write expanded objects. If passed a read-write expanded object pointer, the EEOP_NULLIF code would hand that same pointer to the equality function and then (unless equality was reported) also return the same pointer as its value. This is no good, because a function that receives a read-write expanded object pointer is fully entitled to scribble on or even delete the object, thus corrupting the NULLIF output. (This problem is likely unobservable with the equality functions provided in core Postgres, but it's easy to demonstrate with one coded in plpgsql.) To fix, make sure the pointer passed to the equality function is read-only. We can still return the original read-write pointer as the NULLIF result, allowing optimization of later operations. Per bug #18722 from Alexander Lakhin. This has been wrong since we invented expanded objects, so back-patch to all supported branches. Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/97be02ad0015502fac0b788bc0a4739a398f41d5 Modified Files -------------- src/backend/executor/execExpr.c | 8 ++++++++ src/backend/executor/execExprInterp.c | 14 +++++++++++++- src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++---- src/include/executor/execExpr.h | 1 + src/test/regress/expected/case.out | 8 ++++++++ src/test/regress/sql/case.sql | 5 +++++ 6 files changed, 64 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix NULLIF()'s handling of read-write expanded objects. @ 2024-11-25 23:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-25 23:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix NULLIF()'s handling of read-write expanded objects. If passed a read-write expanded object pointer, the EEOP_NULLIF code would hand that same pointer to the equality function and then (unless equality was reported) also return the same pointer as its value. This is no good, because a function that receives a read-write expanded object pointer is fully entitled to scribble on or even delete the object, thus corrupting the NULLIF output. (This problem is likely unobservable with the equality functions provided in core Postgres, but it's easy to demonstrate with one coded in plpgsql.) To fix, make sure the pointer passed to the equality function is read-only. We can still return the original read-write pointer as the NULLIF result, allowing optimization of later operations. Per bug #18722 from Alexander Lakhin. This has been wrong since we invented expanded objects, so back-patch to all supported branches. Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4aba56adcd29c5d9a6f38f9bc428b916e3d08d5d Modified Files -------------- src/backend/executor/execExpr.c | 8 ++++++++ src/backend/executor/execExprInterp.c | 14 +++++++++++++- src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++---- src/include/executor/execExpr.h | 1 + src/test/regress/expected/case.out | 8 ++++++++ src/test/regress/sql/case.sql | 5 +++++ 6 files changed, 64 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix NULLIF()'s handling of read-write expanded objects. @ 2024-11-25 23:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-25 23:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix NULLIF()'s handling of read-write expanded objects. If passed a read-write expanded object pointer, the EEOP_NULLIF code would hand that same pointer to the equality function and then (unless equality was reported) also return the same pointer as its value. This is no good, because a function that receives a read-write expanded object pointer is fully entitled to scribble on or even delete the object, thus corrupting the NULLIF output. (This problem is likely unobservable with the equality functions provided in core Postgres, but it's easy to demonstrate with one coded in plpgsql.) To fix, make sure the pointer passed to the equality function is read-only. We can still return the original read-write pointer as the NULLIF result, allowing optimization of later operations. Per bug #18722 from Alexander Lakhin. This has been wrong since we invented expanded objects, so back-patch to all supported branches. Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/80cd33bad172c6d625f04d3b4f74f8f00c2a58de Modified Files -------------- src/backend/executor/execExpr.c | 8 ++++++++ src/backend/executor/execExprInterp.c | 14 +++++++++++++- src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++---- src/include/executor/execExpr.h | 1 + src/test/regress/expected/case.out | 8 ++++++++ src/test/regress/sql/case.sql | 5 +++++ 6 files changed, 64 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix NULLIF()'s handling of read-write expanded objects. @ 2024-11-25 23:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-25 23:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix NULLIF()'s handling of read-write expanded objects. If passed a read-write expanded object pointer, the EEOP_NULLIF code would hand that same pointer to the equality function and then (unless equality was reported) also return the same pointer as its value. This is no good, because a function that receives a read-write expanded object pointer is fully entitled to scribble on or even delete the object, thus corrupting the NULLIF output. (This problem is likely unobservable with the equality functions provided in core Postgres, but it's easy to demonstrate with one coded in plpgsql.) To fix, make sure the pointer passed to the equality function is read-only. We can still return the original read-write pointer as the NULLIF result, allowing optimization of later operations. Per bug #18722 from Alexander Lakhin. This has been wrong since we invented expanded objects, so back-patch to all supported branches. Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a1168855e0df9aabb997ffc26dc8ef6afae2429b Modified Files -------------- src/backend/executor/execExpr.c | 8 ++++++++ src/backend/executor/execExprInterp.c | 14 +++++++++++++- src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++---- src/include/executor/execExpr.h | 1 + src/test/regress/expected/case.out | 8 ++++++++ src/test/regress/sql/case.sql | 5 +++++ 6 files changed, 64 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix NULLIF()'s handling of read-write expanded objects. @ 2024-11-25 23:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-25 23:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix NULLIF()'s handling of read-write expanded objects. If passed a read-write expanded object pointer, the EEOP_NULLIF code would hand that same pointer to the equality function and then (unless equality was reported) also return the same pointer as its value. This is no good, because a function that receives a read-write expanded object pointer is fully entitled to scribble on or even delete the object, thus corrupting the NULLIF output. (This problem is likely unobservable with the equality functions provided in core Postgres, but it's easy to demonstrate with one coded in plpgsql.) To fix, make sure the pointer passed to the equality function is read-only. We can still return the original read-write pointer as the NULLIF result, allowing optimization of later operations. Per bug #18722 from Alexander Lakhin. This has been wrong since we invented expanded objects, so back-patch to all supported branches. Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/48a6cd1ae63661528ae2da191e85e377f6443623 Modified Files -------------- src/backend/executor/execExpr.c | 8 ++++++++ src/backend/executor/execExprInterp.c | 14 +++++++++++++- src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++---- src/include/executor/execExpr.h | 1 + src/test/regress/expected/case.out | 8 ++++++++ src/test/regress/sql/case.sql | 5 +++++ 6 files changed, 64 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-11-25 23:10 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-11-25 23:10 pgsql: Fix NULLIF()'s handling of read-write expanded objects. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-25 23:10 pgsql: Fix NULLIF()'s handling of read-write expanded objects. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-25 23:10 pgsql: Fix NULLIF()'s handling of read-write expanded objects. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-25 23:10 pgsql: Fix NULLIF()'s handling of read-write expanded objects. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-25 23:10 pgsql: Fix NULLIF()'s handling of read-write expanded objects. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-25 23:10 pgsql: Fix NULLIF()'s handling of read-write expanded objects. 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