pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger 6+ messages / 1 participants [nested] [flat]
* pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger @ 2024-05-07 22:15 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-07 22:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c5bec5426af989f2a9b0c1f4b97340798fe153f7 Modified Files -------------- src/pl/plpython/expected/plpython_trigger.out | 27 +++++++++++++++++++++++++ src/pl/plpython/plpy_exec.c | 29 ++++++++++++++++++++++++--- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++++++++++++++++++++++ 5 files changed, 80 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger @ 2024-05-07 22:15 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-07 22:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/90d39929a8900ba38a3ded503481867ca3182849 Modified Files -------------- src/pl/plpython/expected/plpython_trigger.out | 27 +++++++++++++++++++++++++ src/pl/plpython/plpy_exec.c | 29 ++++++++++++++++++++++++--- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++++++++++++++++++++++ 5 files changed, 80 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger @ 2024-05-07 22:15 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-07 22:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/be18a12b663181f304d49022a452e31e4df42ff2 Modified Files -------------- src/pl/plpython/expected/plpython_trigger.out | 27 +++++++++++++++++++++++++ src/pl/plpython/plpy_exec.c | 29 ++++++++++++++++++++++++--- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++++++++++++++++++++++ 5 files changed, 80 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger @ 2024-05-07 22:15 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-07 22:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/363e8c2f98b80e039873902b3b3fd003ae09bd9e Modified Files -------------- src/pl/plpython/expected/plpython_trigger.out | 27 +++++++++++++++++++++++++ src/pl/plpython/plpy_exec.c | 29 ++++++++++++++++++++++++--- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++++++++++++++++++++++ 5 files changed, 80 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger @ 2024-05-07 22:15 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-07 22:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/abe60b6a0d276a073fc3f057498a920cdab906a9 Modified Files -------------- src/pl/plpython/expected/plpython_trigger.out | 27 +++++++++++++++++++++++++ src/pl/plpython/plpy_exec.c | 29 ++++++++++++++++++++++++--- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++++++++++++++++++++++ 5 files changed, 80 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger @ 2024-05-07 22:15 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-07 22:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4488142a463c623d3567b1452deb6d768cd0ee9b Modified Files -------------- src/pl/plpython/expected/plpython_trigger.out | 27 ++++++++++++++++++++++++ src/pl/plpython/plpy_exec.c | 30 ++++++++++++++++++++++++--- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 +++++++++++++++++++++ 5 files changed, 81 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-05-07 22:15 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-05-07 22:15 pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger Tom Lane <tgl@sss.pgh.pa.us> 2024-05-07 22:15 pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger Tom Lane <tgl@sss.pgh.pa.us> 2024-05-07 22:15 pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger Tom Lane <tgl@sss.pgh.pa.us> 2024-05-07 22:15 pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger Tom Lane <tgl@sss.pgh.pa.us> 2024-05-07 22:15 pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger Tom Lane <tgl@sss.pgh.pa.us> 2024-05-07 22:15 pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger 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