pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/10d9c9d03cfeadf872b57bae8847624afac87d5e Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d137b14c3cec73a521a504eae645d83e140b1f1c Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/beb6b45ab7470b0412edb565eaa6f48683245d47 Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ba581cf1104261f506377823a25795f0849ce62 Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/98f8cdd48cc5702c0cd3ef896efb957888e848b0 Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e6dc04d436f1c5f173fc8b6e2f722f2d53719a92 Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Fix more race conditions in the newly-added pg_rewind test.
Fix more race conditions in the newly-added pg_rewind test. pg_rewind looks at the control file to check what timeline a server is on. But promotion doesn't immediately write a checkpoint, it merely writes an end-of-recovery WAL record. If pg_rewind runs immediately after promotion, before the checkpoint has completed, it will think think that the server is still on the earlier timeline. We ran into this issue a long time ago already, see commit 484a848a73f. It's a bit bogus that pg_rewind doesn't determine the timeline correctly until the end-of-recovery checkpoint has completed. We probably should fix that. But for now work around it by waiting for the checkpoint to complete before running pg_rewind, like we did in commit 484a848a73f. In the passing, tidy up the new test a little bit. Rerder the INSERTs so that the comments make more sense, remove a spurious CHECKPOINT call after pg_rewind has already run, and add --debug option, so that if this fails again, we'll have more data. Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3ea8e660c0e050826ce06b0ad4dc34ae64c8f850 Modified Files -- src/bin/pg_rewind/t/008_min_recovery_point.pl | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-)
pgsql: Add a couple of regression test cases related to array subscript
Add a couple of regression test cases related to array subscripting. Exercise some error cases that were never reached in the existing regression tests. This is partly for code-coverage reasons, and partly to memorialize the current behavior in advance of planned changes for generic subscripting. Also, I noticed that type_sanity's check to verify that all standard types have array types was never extended when we added arrays for all system catalog rowtypes (f7f70d5e2), nor when we added arrays over domain types (c12d570fa). So do that. Also, since the query's expected output isn't empty, it seems like a good idea to add an ORDER BY to make sure the result stays stable. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0a665bbc43c5a678331fb1b1f44274500eba6563 Modified Files -- src/test/regress/expected/arrays.out | 13 + src/test/regress/expected/rowtypes.out| 8 +++- src/test/regress/expected/type_sanity.out | 12 ++-- src/test/regress/sql/arrays.sql | 5 + src/test/regress/sql/rowtypes.sql | 4 src/test/regress/sql/type_sanity.sql | 12 ++-- 6 files changed, 41 insertions(+), 13 deletions(-)
Re: pgsql: Change the attribute name in pg_stat_replication_slots view.
Hi, On 2020-10-20 04:56:00 +, Amit Kapila wrote: > Change the attribute name in pg_stat_replication_slots view. > > Change the attribute 'name' to 'slot_name' in pg_stat_replication_slots > view to make it clear and that way we will be consistent with the other > places like pg_stat_wal_receiver view where we display the same attribute. > > In the passing, fix the typo in one of the macros in the related code. > > Bump the catversion as we have modified the name in the catalog as well. This is missing a catversion bump... Greetings, Andres Freund
Re: pgsql: Change the attribute name in pg_stat_replication_slots view.
Hi, On 2020-12-07 10:49:11 -0800, Andres Freund wrote: > On 2020-10-20 04:56:00 +, Amit Kapila wrote: > > Change the attribute name in pg_stat_replication_slots view. > > > > Change the attribute 'name' to 'slot_name' in pg_stat_replication_slots > > view to make it clear and that way we will be consistent with the other > > places like pg_stat_wal_receiver view where we display the same attribute. > > > > In the passing, fix the typo in one of the macros in the related code. > > > > Bump the catversion as we have modified the name in the catalog as well. > > This is missing a catversion bump... Err, sorry, this is the wrong thread. Was trying to respond to: commit 01469241b2ff6f17fc0b3f20f01559145ffab29e Author: Fujii Masao Date: 2020-12-02 13:00:15 +0900 Track total number of WAL records, FPIs and bytes generated in the cluster. Not sure what happened. Greetings, Andres Freund
Re: pgsql: Track total number of WAL records, FPIs and bytes generated in t
Hi, On 2020-12-02 04:04:57 +, Fujii Masao wrote: > Track total number of WAL records, FPIs and bytes generated in the cluster. > > Commit 6b466bf5f2 allowed pg_stat_statements to track the number of > WAL records, full page images and bytes that each statement generated. > Similarly this commit allows us to track the cluster-wide WAL statistics > counters. > > New columns wal_records, wal_fpi and wal_bytes are added into the > pg_stat_wal view, and reports the total number of WAL records, > full page images and bytes generated in the , respectively. > > Author: Masahiro Ikeda > Reviewed-by: Amit Kapila, Movead Li, Kyotaro Horiguchi, Fujii Masao > Discussion: > https://postgr.es/m/[email protected] This is missing a catversion bump, due to the changes in view names. Noticed that because I got errors like -- There must be only one record select count(*) = 1 as ok from pg_stat_wal; - ok - - t -(1 row) - +ERROR: function return row and query-specified return row do not match +DETAIL: Returned row contains 5 attributes, but query expects 2. -- This is to record the prevailing planner enable_foo settings during -- a regression test run. when running tests against a pre-existing cluster after rebasing a development tree. Greetings, Andres Freund
pgsql: Avoid using tuple from syscache for update of pg_database.datfro
Avoid using tuple from syscache for update of pg_database.datfrozenxid pg_database.datfrozenxid gets updated using an in-place update at the end of vacuum or autovacuum. Since 96cdeae, as pg_database has a toast relation, it is possible for a pg_database tuple to have toast values if there is a large set of ACLs in place. In such a case, the in-place update would fail because of the flattening of the toast values done for the catcache entry fetched. Instead of using a copy from the catcache, this changes the logic to fetch the copy of the tuple by directly scanning pg_database. Per the lack of complaints on the matter, no backpatch is done. Note that before 96cdeae, attempting to insert such a tuple to pg_database would cause a "row is too big" error, so the end-of-vacuum problem was not reachable. Author: Ashwin Agrawal, Junfeng Yang Discussion: https://postgr.es/m/dm5pr0501mb38800d9e4605bca72dd35557cc...@dm5pr0501mb3880.namprd05.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/947789f1f5fb61daf663f26325cbe7cad8197d58 Modified Files -- src/backend/access/heap/heapam.c | 4 src/backend/commands/vacuum.c| 20 ++-- 2 files changed, 22 insertions(+), 2 deletions(-)
pgsql: jit: configure: Explicitly reference 'native' component.
jit: configure: Explicitly reference 'native' component. Until recently 'native' was implicitly included via 'orcjit', but a change included in LLVM 11 (not yet released) removed a number of such indirect component references. Reported-By: Fabien COELHO Reported-By: Andres Freund Reported-By: Thomas Munro Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4f64daf73af76cbf32a01c7cba1c3a6fccf3062a Modified Files -- config/llvm.m4 | 1 + configure | 1 + 2 files changed, 2 insertions(+)
pgsql: backpatch "jit: Add support for LLVM 12."
backpatch "jit: Add support for LLVM 12." As there haven't been problem on the buildfarm due to this change, backpatch 6c57f2ed16e now. Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6a192c77d21b5eafc7f431cbf5e7ecdd6c8b5462 Modified Files -- src/backend/jit/llvm/llvmjit.c | 458 +++ src/tools/pgindent/typedefs.list | 1 + 2 files changed, 374 insertions(+), 85 deletions(-)
pgsql: jit: Correct parameter type for generated expression evaluation
jit: Correct parameter type for generated expression evaluation functions. clang only uses the 'i1' type for scalar booleans, not for pointers to booleans (as the pointer might be pointing into a larger memory allocation). Therefore a pointer-to-bool needs to the "storage" boolean. There's no known case of wrong code generation due to this, but it seems quite possible that it could cause problems (see e.g. 72559438f92). Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01c6370a32e5875a63400c6e465de775a51ef1b8 Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: jit: Correct parameter type for generated expression evaluation
jit: Correct parameter type for generated expression evaluation functions. clang only uses the 'i1' type for scalar booleans, not for pointers to booleans (as the pointer might be pointing into a larger memory allocation). Therefore a pointer-to-bool needs to the "storage" boolean. There's no known case of wrong code generation due to this, but it seems quite possible that it could cause problems (see e.g. 72559438f92). Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/27b57f806dc2da9d43657c0ef9569be9aac11e1c Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: backpatch "jit: Add support for LLVM 12."
backpatch "jit: Add support for LLVM 12." As there haven't been problem on the buildfarm due to this change, backpatch 6c57f2ed16e now. Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fa7a52fb9943aa1c362a19fa886db284c82b62cd Modified Files -- src/backend/jit/llvm/llvmjit.c | 458 +++ src/tools/pgindent/typedefs.list | 1 + 2 files changed, 374 insertions(+), 85 deletions(-)
pgsql: jit: configure: Explicitly reference 'native' component.
jit: configure: Explicitly reference 'native' component. Until recently 'native' was implicitly included via 'orcjit', but a change included in LLVM 11 (not yet released) removed a number of such indirect component references. Reported-By: Fabien COELHO Reported-By: Andres Freund Reported-By: Thomas Munro Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b07490b912467e6760b3a410347959c3eb9fc306 Modified Files -- config/llvm.m4 | 1 + configure | 1 + 2 files changed, 2 insertions(+)
pgsql: backpatch "jit: Add support for LLVM 12."
backpatch "jit: Add support for LLVM 12." As there haven't been problem on the buildfarm due to this change, backpatch 6c57f2ed16e now. Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/90eb343ef3929a0cce5b6940781680cd4f7801f2 Modified Files -- src/backend/jit/llvm/llvmjit.c | 458 +++ src/tools/pgindent/typedefs.list | 1 + 2 files changed, 374 insertions(+), 85 deletions(-)
pgsql: jit: Correct parameter type for generated expression evaluation
jit: Correct parameter type for generated expression evaluation functions. clang only uses the 'i1' type for scalar booleans, not for pointers to booleans (as the pointer might be pointing into a larger memory allocation). Therefore a pointer-to-bool needs to the "storage" boolean. There's no known case of wrong code generation due to this, but it seems quite possible that it could cause problems (see e.g. 72559438f92). Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1e16ad101459432418d61a0faf2c7692ad76459b Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: jit: configure: Explicitly reference 'native' component.
jit: configure: Explicitly reference 'native' component. Until recently 'native' was implicitly included via 'orcjit', but a change included in LLVM 11 (not yet released) removed a number of such indirect component references. Reported-By: Fabien COELHO Reported-By: Andres Freund Reported-By: Thomas Munro Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f4f924b3ed77ff8b3a6901a545e7c2943edcf9a1 Modified Files -- config/llvm.m4 | 1 + configure | 1 + 2 files changed, 2 insertions(+)
pgsql: jit: configure: Explicitly reference 'native' component.
jit: configure: Explicitly reference 'native' component. Until recently 'native' was implicitly included via 'orcjit', but a change included in LLVM 11 (not yet released) removed a number of such indirect component references. Reported-By: Fabien COELHO Reported-By: Andres Freund Reported-By: Thomas Munro Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9543f0861b1d9b566be88edae21f24fb1377f45c Modified Files -- config/llvm.m4 | 1 + configure | 1 + 2 files changed, 2 insertions(+)
pgsql: jit: Correct parameter type for generated expression evaluation
jit: Correct parameter type for generated expression evaluation functions. clang only uses the 'i1' type for scalar booleans, not for pointers to booleans (as the pointer might be pointing into a larger memory allocation). Therefore a pointer-to-bool needs to the "storage" boolean. There's no known case of wrong code generation due to this, but it seems quite possible that it could cause problems (see e.g. 72559438f92). Author: Andres Freund Discussion: https://postgr.es/m/[email protected] Backpatch: 11-, where jit support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5da871bfa1ba41768ecd7786293d9b81dcf1b667 Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/28d1601ad988790c3c53d7ffd24ef6d2366d4457 Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dfd8bf2b9255f361d5541260a83ce634216c40f3 Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5ba1df0f14d19a32c69adf97d452726fa6a28e02 Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/95992e5ed93d142d64efb020a51148d39678df6a Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b88afd8b6124270a4eead676a5dd56ee7d32a74d Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f95d9fd8153cb1b7da55f425bf217482e4943d2e Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: pgcrypto: Detect errors with EVP calls from OpenSSL
pgcrypto: Detect errors with EVP calls from OpenSSL The following routines are called within pgcrypto when handling digests but there were no checks for failures: - EVP_MD_CTX_size (can fail with -1 as of 3.0.0) - EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0) - EVP_DigestInit_ex - EVP_DigestUpdate - EVP_DigestFinal_ex A set of elog(ERROR) is added by this commit to detect such failures, that should never happen except in the event of a processing failure internal to OpenSSL. Note that it would be possible to use ERR_reason_error_string() to get more context about such errors, but these refer mainly to the internals of OpenSSL, so it is not really obvious how useful that would be. This is left out for simplicity. Per report from Coverity. Thanks to Tom Lane for the discussion. Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d7ecba937b909c26cc266d06261ddaf5a540630e Modified Files -- contrib/pgcrypto/openssl.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
