pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix plpgsql's handling of "simple" expression evaluation. 12+ messages / 1 participants [nested] [flat]
* pgsql: Fix plpgsql's handling of "simple" expression evaluation. @ 2010-10-28 17:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2010-10-28 17:03 UTC (permalink / raw) To: pgsql-committers Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches. Branch ------ master Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=8ce22dd4c51b6e8155889653c0116cad138... Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 28 +++++++++++++++++++- src/pl/plpgsql/src/plpgsql.h | 8 +++-- src/test/regress/expected/plpgsql.out | 47 +++++++++++++++++++++++++++++++++ src/test/regress/sql/plpgsql.sql | 42 +++++++++++++++++++++++++++++ 4 files changed, 121 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of "simple" expression evaluation. @ 2010-10-28 17:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2010-10-28 17:03 UTC (permalink / raw) To: pgsql-committers Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches. Branch ------ REL8_3_STABLE Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=ed78eefed2b21517e3f4abaf95081c8f780... Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 31 +++++++++++++++++++++- src/pl/plpgsql/src/plpgsql.h | 7 +++-- src/test/regress/expected/plpgsql.out | 47 +++++++++++++++++++++++++++++++++ src/test/regress/sql/plpgsql.sql | 42 +++++++++++++++++++++++++++++ 4 files changed, 123 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of "simple" expression evaluation. @ 2010-10-28 17:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2010-10-28 17:03 UTC (permalink / raw) To: pgsql-committers Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches. Branch ------ REL9_0_STABLE Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=381d6a05aecbade0bf536325ace36f1507d... Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 28 +++++++++++++++++++- src/pl/plpgsql/src/plpgsql.h | 8 +++-- src/test/regress/expected/plpgsql.out | 47 +++++++++++++++++++++++++++++++++ src/test/regress/sql/plpgsql.sql | 42 +++++++++++++++++++++++++++++ 4 files changed, 121 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of "simple" expression evaluation. @ 2010-10-28 17:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2010-10-28 17:03 UTC (permalink / raw) To: pgsql-committers Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches. Branch ------ REL8_2_STABLE Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=2487e8d8c8ca0014d9c02de16d0bdce62da... Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 20 +++++++++++++- src/pl/plpgsql/src/plpgsql.h | 7 +++-- src/test/regress/expected/plpgsql.out | 47 +++++++++++++++++++++++++++++++++ src/test/regress/sql/plpgsql.sql | 42 +++++++++++++++++++++++++++++ 4 files changed, 112 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of "simple" expression evaluation. @ 2010-10-28 17:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2010-10-28 17:03 UTC (permalink / raw) To: pgsql-committers Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches. Branch ------ REL8_1_STABLE Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=c0486e9dea9135d434b0451becab91bee28... Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 20 +++++++++++++- src/pl/plpgsql/src/plpgsql.h | 8 +++-- src/test/regress/expected/plpgsql.out | 47 +++++++++++++++++++++++++++++++++ src/test/regress/sql/plpgsql.sql | 42 +++++++++++++++++++++++++++++ 4 files changed, 113 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of "simple" expression evaluation. @ 2010-10-28 17:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2010-10-28 17:03 UTC (permalink / raw) To: pgsql-committers Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches. Branch ------ REL8_4_STABLE Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=f44b6fc9f1334e3f52ed3c5430e008637af... Modified Files -------------- src/pl/plpgsql/src/pl_exec.c | 30 ++++++++++++++++++++- src/pl/plpgsql/src/plpgsql.h | 8 +++-- src/test/regress/expected/plpgsql.out | 47 +++++++++++++++++++++++++++++++++ src/test/regress/sql/plpgsql.sql | 42 +++++++++++++++++++++++++++++ 4 files changed, 123 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of simple expressions in scrollable curso @ 2025-03-21 15:31 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2025-03-21 15:31 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of simple expressions in scrollable cursors. exec_save_simple_expr did not account for the possibility that standard_planner would stick a Materialize node atop the plan of even a simple Result, if CURSOR_OPT_SCROLL is set. This led to an "unexpected plan node type" error. This is a very old bug, but it'd only be reached by declaring a cursor for a "SELECT simple-expression" query and explicitly marking it scrollable, which is an odd thing to do. So the lack of prior reports isn't too surprising. Bug: #18859 Reported-by: Olleg Samoylov <splarv@ya.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7fe312f6092f47724a29e30fb2992bd2bc287687 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_simple.out | 11 +++++++++++ src/pl/plpgsql/src/pl_exec.c | 12 +++++++----- src/pl/plpgsql/src/sql/plpgsql_simple.sql | 12 ++++++++++++ 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of simple expressions in scrollable curso @ 2025-03-21 15:31 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2025-03-21 15:31 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of simple expressions in scrollable cursors. exec_save_simple_expr did not account for the possibility that standard_planner would stick a Materialize node atop the plan of even a simple Result, if CURSOR_OPT_SCROLL is set. This led to an "unexpected plan node type" error. This is a very old bug, but it'd only be reached by declaring a cursor for a "SELECT simple-expression" query and explicitly marking it scrollable, which is an odd thing to do. So the lack of prior reports isn't too surprising. Bug: #18859 Reported-by: Olleg Samoylov <splarv@ya.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1353b1161a790e64507428e33cc0c5975f26474b Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_simple.out | 11 +++++++++++ src/pl/plpgsql/src/pl_exec.c | 12 +++++++----- src/pl/plpgsql/src/sql/plpgsql_simple.sql | 12 ++++++++++++ 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of simple expressions in scrollable curso @ 2025-03-21 15:31 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2025-03-21 15:31 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of simple expressions in scrollable cursors. exec_save_simple_expr did not account for the possibility that standard_planner would stick a Materialize node atop the plan of even a simple Result, if CURSOR_OPT_SCROLL is set. This led to an "unexpected plan node type" error. This is a very old bug, but it'd only be reached by declaring a cursor for a "SELECT simple-expression" query and explicitly marking it scrollable, which is an odd thing to do. So the lack of prior reports isn't too surprising. Bug: #18859 Reported-by: Olleg Samoylov <splarv@ya.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a28c1fb619bfbb82e4dc4965502d33f5a77bde52 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_simple.out | 11 +++++++++++ src/pl/plpgsql/src/pl_exec.c | 12 +++++++----- src/pl/plpgsql/src/sql/plpgsql_simple.sql | 12 ++++++++++++ 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of simple expressions in scrollable curso @ 2025-03-21 15:31 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2025-03-21 15:31 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of simple expressions in scrollable cursors. exec_save_simple_expr did not account for the possibility that standard_planner would stick a Materialize node atop the plan of even a simple Result, if CURSOR_OPT_SCROLL is set. This led to an "unexpected plan node type" error. This is a very old bug, but it'd only be reached by declaring a cursor for a "SELECT simple-expression" query and explicitly marking it scrollable, which is an odd thing to do. So the lack of prior reports isn't too surprising. Bug: #18859 Reported-by: Olleg Samoylov <splarv@ya.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5e56efa7c0e03f9d5305a925b2a44b687a2f1821 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_simple.out | 11 +++++++++++ src/pl/plpgsql/src/pl_exec.c | 12 +++++++----- src/pl/plpgsql/src/sql/plpgsql_simple.sql | 12 ++++++++++++ 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of simple expressions in scrollable curso @ 2025-03-21 15:31 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2025-03-21 15:31 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of simple expressions in scrollable cursors. exec_save_simple_expr did not account for the possibility that standard_planner would stick a Materialize node atop the plan of even a simple Result, if CURSOR_OPT_SCROLL is set. This led to an "unexpected plan node type" error. This is a very old bug, but it'd only be reached by declaring a cursor for a "SELECT simple-expression" query and explicitly marking it scrollable, which is an odd thing to do. So the lack of prior reports isn't too surprising. Bug: #18859 Reported-by: Olleg Samoylov <splarv@ya.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c196c610b3391209ad43db22905ef5725dad559c Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_simple.out | 11 +++++++++++ src/pl/plpgsql/src/pl_exec.c | 12 +++++++----- src/pl/plpgsql/src/sql/plpgsql_simple.sql | 12 ++++++++++++ 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
* pgsql: Fix plpgsql's handling of simple expressions in scrollable curso @ 2025-03-21 15:31 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 12+ messages in thread From: Tom Lane @ 2025-03-21 15:31 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of simple expressions in scrollable cursors. exec_save_simple_expr did not account for the possibility that standard_planner would stick a Materialize node atop the plan of even a simple Result, if CURSOR_OPT_SCROLL is set. This led to an "unexpected plan node type" error. This is a very old bug, but it'd only be reached by declaring a cursor for a "SELECT simple-expression" query and explicitly marking it scrollable, which is an odd thing to do. So the lack of prior reports isn't too surprising. Bug: #18859 Reported-by: Olleg Samoylov <splarv@ya.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0f60e1fba13748811f266c0564e1b3fe834299c0 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_simple.out | 11 +++++++++++ src/pl/plpgsql/src/pl_exec.c | 12 +++++++----- src/pl/plpgsql/src/sql/plpgsql_simple.sql | 12 ++++++++++++ 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2025-03-21 15:31 UTC | newest] Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2010-10-28 17:03 pgsql: Fix plpgsql's handling of "simple" expression evaluation. Tom Lane <tgl@sss.pgh.pa.us> 2010-10-28 17:03 pgsql: Fix plpgsql's handling of "simple" expression evaluation. Tom Lane <tgl@sss.pgh.pa.us> 2010-10-28 17:03 pgsql: Fix plpgsql's handling of "simple" expression evaluation. Tom Lane <tgl@sss.pgh.pa.us> 2010-10-28 17:03 pgsql: Fix plpgsql's handling of "simple" expression evaluation. Tom Lane <tgl@sss.pgh.pa.us> 2010-10-28 17:03 pgsql: Fix plpgsql's handling of "simple" expression evaluation. Tom Lane <tgl@sss.pgh.pa.us> 2010-10-28 17:03 pgsql: Fix plpgsql's handling of "simple" expression evaluation. Tom Lane <tgl@sss.pgh.pa.us> 2025-03-21 15:31 pgsql: Fix plpgsql's handling of simple expressions in scrollable curso Tom Lane <tgl@sss.pgh.pa.us> 2025-03-21 15:31 pgsql: Fix plpgsql's handling of simple expressions in scrollable curso Tom Lane <tgl@sss.pgh.pa.us> 2025-03-21 15:31 pgsql: Fix plpgsql's handling of simple expressions in scrollable curso Tom Lane <tgl@sss.pgh.pa.us> 2025-03-21 15:31 pgsql: Fix plpgsql's handling of simple expressions in scrollable curso Tom Lane <tgl@sss.pgh.pa.us> 2025-03-21 15:31 pgsql: Fix plpgsql's handling of simple expressions in scrollable curso Tom Lane <tgl@sss.pgh.pa.us> 2025-03-21 15:31 pgsql: Fix plpgsql's handling of simple expressions in scrollable curso 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