pgsql: Fix typo in logicalfuncs.c.
Fix typo in logicalfuncs.c. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACX1mVtw8LWEnZgnpPdk2bPFR1xX2ZN+8GfXCffyip_9=q...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a89850a57e0557bd3faab32398eb2d9536f6e2a4 Modified Files -- src/backend/replication/logical/logicalfuncs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Add further debug info to help debug 019_replslot_limit.pl failu
Add further debug info to help debug 019_replslot_limit.pl failures. See also afdeff10526. Failures after that commit provided a few more hints, but not yet enough to understand what's going on. In 019_replslot_limit.pl shut down nodes with fast instead of immediate mode if we observe the failure mode. That should tell us whether the failures we're observing are just a timing issue under high load. PGCTLTIMEOUT should prevent buildfarm animals from hanging endlessly. Also adds a bit more logging to replication slot drop and ShutdownPostgres(). Discussion: https://postgr.es/m/20220225192941.hqnvefgdzaro6...@alap3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fe0972ee5e6f8a663c5cf3f24ef98987c503da95 Modified Files -- src/backend/replication/slot.c| 13 + src/backend/storage/lmgr/lwlock.c | 7 +++ src/backend/utils/init/postinit.c | 17 + src/include/storage/lwlock.h | 1 + src/test/recovery/t/019_replslot_limit.pl | 18 +- 5 files changed, 55 insertions(+), 1 deletion(-)
pgsql: Disallow execution of SPI functions during plperl function compi
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f08...@intellasoft.net Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/31befa6be620122afd95c6a64bc313efe6e1ceea Modified Files -- src/pl/plperl/plperl.c | 33 +++-- 1 file changed, 31 insertions(+), 2 deletions(-)
pgsql: Disallow execution of SPI functions during plperl function compi
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f08...@intellasoft.net Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ac910bb2328ff107359d009aaf821c01559cef19 Modified Files -- src/pl/plperl/plperl.c | 33 +++-- 1 file changed, 31 insertions(+), 2 deletions(-)
pgsql: Disallow execution of SPI functions during plperl function compi
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f08...@intellasoft.net Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0f7b62f29d16c771486418f88473ce07b605bb92 Modified Files -- src/pl/plperl/plperl.c | 33 +++-- 1 file changed, 31 insertions(+), 2 deletions(-)
pgsql: Disallow execution of SPI functions during plperl function compi
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f08...@intellasoft.net Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4936747c477270e133e622bf6d7a12fa246cf3a7 Modified Files -- src/pl/plperl/plperl.c | 29 +++-- 1 file changed, 27 insertions(+), 2 deletions(-)
pgsql: Disallow execution of SPI functions during plperl function compi
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f08...@intellasoft.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/638300fef541fb9393caa1ee8821a639816301d1 Modified Files -- src/pl/plperl/plperl.c | 33 +++-- 1 file changed, 31 insertions(+), 2 deletions(-)
pgsql: Disallow execution of SPI functions during plperl function compi
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f08...@intellasoft.net Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b2d762a283dc65b2168c3555302e7a23bc377e1 Modified Files -- src/pl/plperl/plperl.c | 33 +++-- 1 file changed, 31 insertions(+), 2 deletions(-)
pgsql: pg_waldump: Fix error message for WAL files smaller than XLOG_BL
pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ. When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while determining the wal_segment_size, pg_waldump checked errno, despite errno not being set by the short read. Resulting in a bogus error message. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota@gmail.com Backpatch: 11-, the bug was introducedin fc49e24fa Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9ff7fd9063ce918e458a643b53eda1cf95f7d115 Modified Files -- src/bin/pg_waldump/pg_waldump.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-)
pgsql: pg_waldump: Fix error message for WAL files smaller than XLOG_BL
pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ. When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while determining the wal_segment_size, pg_waldump checked errno, despite errno not being set by the short read. Resulting in a bogus error message. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota@gmail.com Backpatch: 11-, the bug was introducedin fc49e24fa Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0b1020a96d8e14ba5c5fe22f825c3093160aa83b Modified Files -- src/bin/pg_waldump/pg_waldump.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-)
pgsql: pg_waldump: Fix error message for WAL files smaller than XLOG_BL
pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ. When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while determining the wal_segment_size, pg_waldump checked errno, despite errno not being set by the short read. Resulting in a bogus error message. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota@gmail.com Backpatch: 11-, the bug was introducedin fc49e24fa Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/51c34165614bde5d44a356ba5f1f4f79d8893103 Modified Files -- src/bin/pg_waldump/pg_waldump.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)
pgsql: pg_waldump: Fix error message for WAL files smaller than XLOG_BL
pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ. When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while determining the wal_segment_size, pg_waldump checked errno, despite errno not being set by the short read. Resulting in a bogus error message. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota@gmail.com Backpatch: 11-, the bug was introducedin fc49e24fa Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5407241a8ec1af770010d05715f0e3a31db5c518 Modified Files -- src/bin/pg_waldump/pg_waldump.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-)
pgsql: pg_waldump: Fix error message for WAL files smaller than XLOG_BL
pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ. When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while determining the wal_segment_size, pg_waldump checked errno, despite errno not being set by the short read. Resulting in a bogus error message. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota@gmail.com Backpatch: 11-, the bug was introducedin fc49e24fa Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd83cb953606b94966981056e79dbb6c48751055 Modified Files -- src/bin/pg_waldump/pg_waldump.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-)
