[COMMITTERS] pgsql: Avoid dump/reload problems when using both plpython2 and plpytho
Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.) Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/866566a690bb9916dcd294807e65a6e173396530 Modified Files -- src/pl/plpython/plpy_main.c | 81 +-- 1 file changed, 71 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid dump/reload problems when using both plpython2 and plpytho
Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.) Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/22815752effdec0df091244563b4398bd36a91b0 Modified Files -- src/pl/plpython/plpy_main.c | 81 +-- 1 file changed, 71 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid dump/reload problems when using both plpython2 and plpytho
Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.) Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/db8fa56d6ad15621ad4f74667bfd59533408ce16 Modified Files -- src/pl/plpython/plpy_main.c | 81 +-- 1 file changed, 71 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid dump/reload problems when using both plpython2 and plpytho
Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.) Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0ddeaba7ed88151fd90b5d13d50beca2aff0ab39 Modified Files -- src/pl/plpython/plpy_main.c | 81 +-- 1 file changed, 71 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid dump/reload problems when using both plpython2 and plpytho
Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.) Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/3843ba510bb1586ba8bc29ecf8df7d4fb60d02bb Modified Files -- src/pl/plpython/plpy_main.c | 81 +-- 1 file changed, 71 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use LOAD not actual code execution to pull in plpython library.
Use LOAD not actual code execution to pull in plpython library. Commit 866566a690bb9916 is insufficient to prevent dump/reload failures when using transform modules in a database with both plpython2 and plpython3 installed. The reason is that the transform extension scripts use DO blocks as a mechanism to pull in the libpython library before creating the transform function. It's necessary to preload the library because the dynamic loader won't do it for us on every platform, leading to "unresolved symbol" failures when the transform library is loaded. But it's *not* necessary to execute Python code, and doing so will provoke a multiple-Pythons-are-loaded error even after the preceding commit. To fix, use LOAD instead of a DO block. That requires superuser privilege, but creation of a C function does anyway. It also embeds knowledge of the underlying library name for each PL language; but that's wired into the initdb-time contents of pg_pltemplate too, so that doesn't seem like a large problem either. Note that CREATE TRANSFORM as such doesn't call the language module at all. Per a report from Paul Jones. Back-patch to 9.5 where transform modules were introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/fb6fcbd33fbbd6d31fa2b39938e60ecb48dc4de4 Modified Files -- contrib/hstore_plperl/hstore_plperl--1.0.sql |2 +- contrib/hstore_plperl/hstore_plperlu--1.0.sql |2 +- contrib/hstore_plpython/hstore_plpython2u--1.0.sql |2 +- contrib/hstore_plpython/hstore_plpython3u--1.0.sql |2 +- contrib/hstore_plpython/hstore_plpythonu--1.0.sql |2 +- contrib/ltree_plpython/ltree_plpython2u--1.0.sql |2 +- contrib/ltree_plpython/ltree_plpython3u--1.0.sql |2 +- contrib/ltree_plpython/ltree_plpythonu--1.0.sql|2 +- 8 files changed, 8 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use LOAD not actual code execution to pull in plpython library.
Use LOAD not actual code execution to pull in plpython library. Commit 866566a690bb9916 is insufficient to prevent dump/reload failures when using transform modules in a database with both plpython2 and plpython3 installed. The reason is that the transform extension scripts use DO blocks as a mechanism to pull in the libpython library before creating the transform function. It's necessary to preload the library because the dynamic loader won't do it for us on every platform, leading to "unresolved symbol" failures when the transform library is loaded. But it's *not* necessary to execute Python code, and doing so will provoke a multiple-Pythons-are-loaded error even after the preceding commit. To fix, use LOAD instead of a DO block. That requires superuser privilege, but creation of a C function does anyway. It also embeds knowledge of the underlying library name for each PL language; but that's wired into the initdb-time contents of pg_pltemplate too, so that doesn't seem like a large problem either. Note that CREATE TRANSFORM as such doesn't call the language module at all. Per a report from Paul Jones. Back-patch to 9.5 where transform modules were introduced. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/5ef26b8de3a12b0766334a19665d8b0f494a6af8 Modified Files -- contrib/hstore_plperl/hstore_plperl--1.0.sql |2 +- contrib/hstore_plperl/hstore_plperlu--1.0.sql |2 +- contrib/hstore_plpython/hstore_plpython2u--1.0.sql |2 +- contrib/hstore_plpython/hstore_plpython3u--1.0.sql |2 +- contrib/hstore_plpython/hstore_plpythonu--1.0.sql |2 +- contrib/ltree_plpython/ltree_plpython2u--1.0.sql |2 +- contrib/ltree_plpython/ltree_plpython3u--1.0.sql |2 +- contrib/ltree_plpython/ltree_plpythonu--1.0.sql|2 +- 8 files changed, 8 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove no-longer-needed old-style check for incompatible plpytho
Remove no-longer-needed old-style check for incompatible plpythons. Commit 866566a690bb9916 introduced a new mechanism for incompatible plpythons to detect each other. I left the old mechanism in place, because it seems possible that a plpython predating that commit might be used with one postdating it. (This would require updating plpython3 but not plpython2 or vice versa, but that seems well within the realm of possibility.) However, surely it will not be able to happen in 9.6 or later, so we can delete the old mechanism in HEAD. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/796d1e889f2b5f88b33a425fdfd08d7906cbd66a Modified Files -- src/pl/plpython/plpy_main.c | 29 ++--- 1 file changed, 2 insertions(+), 27 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Maintain local LogwrtResult consistently
Maintain local LogwrtResult consistently Teach GetFlushRecPtr() to update LogwrtResult cache as performed by all other functions in xlog.c Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/1e29e6324ca7d52eb751c8d63881d1f7c44e3921 Modified Files -- src/backend/access/transam/xlog.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Add new user fn pg_current_xlog_flush_location()
Add new user fn pg_current_xlog_flush_location() Tomas Vondra, reviewed by Michael Paquier and Amit Kapila Minor edits by me Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e63bb4549a2f47b86de9fc21c9f8b00440f34f99 Modified Files -- doc/src/sgml/func.sgml | 23 +-- src/backend/access/transam/xlogfuncs.c | 21 + src/include/access/xlog_fn.h |1 + src/include/catalog/pg_proc.h |2 ++ 4 files changed, 41 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
