pgsql: doc: Add additional index entries for progress reporting views.
doc: Add additional index entries for progress reporting views. In the docs, the index entries for progress reporting views link to the "Viewing Statistics" section, but previously they did not link to the dedicated section (e.g., "ANALYZE Progress Reporting") for each view. This was inconvenient when finding the section describing the detailed information about each view, from the index. This commit adds additional index entries linking to those dedicated sections. Author: Fujii Masao Reviewed-by: Shinya Kato Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0a4db67b5ed05c4013ea968930af36853f088404 Modified Files -- doc/src/sgml/monitoring.sgml | 20 1 file changed, 20 insertions(+)
pgsql: docs: ulink all references to RFC's
docs: ulink all references to RFC's Make sure that the first mentions of RFC's are ulinked to their ietf.org entry, and subsequent ones are marked as acronyms. This makes references to RFC's consistent across the documentation. Author: Daniel Gustafsson Discussion: https://www.postgresql.org/message-id/2C697878-4D01-4F06-8312-2FEDE931E973%40yesql.se Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/415dc2009683904f337a1837b6b4eb7f31c4dc55 Modified Files -- doc/src/sgml/catalogs.sgml| 2 +- doc/src/sgml/charset.sgml | 2 +- doc/src/sgml/client-auth.sgml | 19 --- doc/src/sgml/datatype.sgml| 6 -- doc/src/sgml/ecpg.sgml| 2 +- doc/src/sgml/func.sgml| 2 +- doc/src/sgml/json.sgml| 4 ++-- doc/src/sgml/libpq.sgml | 5 +++-- doc/src/sgml/pgcrypto.sgml| 7 --- doc/src/sgml/protocol.sgml| 6 -- doc/src/sgml/textsearch.sgml | 6 +++--- doc/src/sgml/uuid-ossp.sgml | 5 +++-- 12 files changed, 39 insertions(+), 27 deletions(-)
pgsql: Avoid memcpy() with a NULL source pointer and count == 0
Avoid memcpy() with a NULL source pointer and count == 0 When memcpy() is called on a pointer, the compiler is entitled to assume that the pointer is not null, which can lead to optimizing nearby code in potentially undesirable ways. We still want such optimizations (gcc's -fdelete-null-pointer-checks) in cases where they're valid. Related: commit 13bba02271dc. Backpatch to pg11, where this particular instance appeared. Reported-by: Ranier Vilela Reported-by: Zhihong Yu Discussion: https://postgr.es/m/caeudqapundmqkr5flrckxq7+ib44i7s+kk93pyvths85png...@mail.gmail.com Discussion: https://postgr.es/m/calnj-vsdhwsm5f4tnnn1cdlhvxmve_s+v3nr5gwnrmcpnb2...@mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f0ff52f25cb9773de67303a77e6afe3b8a2c4d48 Modified Files -- src/backend/commands/indexcmds.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Avoid memcpy() with a NULL source pointer and count == 0
Avoid memcpy() with a NULL source pointer and count == 0 When memcpy() is called on a pointer, the compiler is entitled to assume that the pointer is not null, which can lead to optimizing nearby code in potentially undesirable ways. We still want such optimizations (gcc's -fdelete-null-pointer-checks) in cases where they're valid. Related: commit 13bba02271dc. Backpatch to pg11, where this particular instance appeared. Reported-by: Ranier Vilela Reported-by: Zhihong Yu Discussion: https://postgr.es/m/caeudqapundmqkr5flrckxq7+ib44i7s+kk93pyvths85png...@mail.gmail.com Discussion: https://postgr.es/m/calnj-vsdhwsm5f4tnnn1cdlhvxmve_s+v3nr5gwnrmcpnb2...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5a1d1b9540a4f5bf4ee6761a17b21ad7c0012b49 Modified Files -- src/backend/commands/indexcmds.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Avoid memcpy() with a NULL source pointer and count == 0
Avoid memcpy() with a NULL source pointer and count == 0 When memcpy() is called on a pointer, the compiler is entitled to assume that the pointer is not null, which can lead to optimizing nearby code in potentially undesirable ways. We still want such optimizations (gcc's -fdelete-null-pointer-checks) in cases where they're valid. Related: commit 13bba02271dc. Backpatch to pg11, where this particular instance appeared. Reported-by: Ranier Vilela Reported-by: Zhihong Yu Discussion: https://postgr.es/m/caeudqapundmqkr5flrckxq7+ib44i7s+kk93pyvths85png...@mail.gmail.com Discussion: https://postgr.es/m/calnj-vsdhwsm5f4tnnn1cdlhvxmve_s+v3nr5gwnrmcpnb2...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/677f74e5bb8360122ebf2f473d7169ed65ce4dba Modified Files -- src/backend/commands/indexcmds.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Avoid memcpy() with a NULL source pointer and count == 0
Avoid memcpy() with a NULL source pointer and count == 0 When memcpy() is called on a pointer, the compiler is entitled to assume that the pointer is not null, which can lead to optimizing nearby code in potentially undesirable ways. We still want such optimizations (gcc's -fdelete-null-pointer-checks) in cases where they're valid. Related: commit 13bba02271dc. Backpatch to pg11, where this particular instance appeared. Reported-by: Ranier Vilela Reported-by: Zhihong Yu Discussion: https://postgr.es/m/caeudqapundmqkr5flrckxq7+ib44i7s+kk93pyvths85png...@mail.gmail.com Discussion: https://postgr.es/m/calnj-vsdhwsm5f4tnnn1cdlhvxmve_s+v3nr5gwnrmcpnb2...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/49aaabdf8d0b85cbf19537bb8bc12856f2e9dc4d Modified Files -- src/backend/commands/indexcmds.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f00c4400270f21905305a4648d1f3d57400a2e15 Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 19 +++ src/test/regress/sql/create_table_like.sql | 8 8 files changed, 43 insertions(+), 3 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5f9b05ada1bb4b5576944227a2d330cde29683cb Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 21 + src/test/regress/sql/create_table_like.sql | 8 8 files changed, 45 insertions(+), 3 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/28bb8c496691e0fb60f49eac08b4dc1d8bdd6b4a Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 21 + src/test/regress/sql/create_table_like.sql | 8 8 files changed, 45 insertions(+), 3 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb500296dfa6cffdd4dfdc8175e2173c6074f20a Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 19 +++ src/test/regress/sql/create_table_like.sql | 8 8 files changed, 43 insertions(+), 3 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f7f83a55bf6051818a0e4387d718867ecfa8561b Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 21 + src/test/regress/sql/create_table_like.sql | 8 8 files changed, 45 insertions(+), 3 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dffc82a5b9d48bded63e1beed718b24bbf58c6a4 Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 21 + src/test/regress/sql/create_table_like.sql | 8 8 files changed, 45 insertions(+), 3 deletions(-)
pgsql: Ensure that expandTableLikeClause() re-examines the same table.
Ensure that expandTableLikeClause() re-examines the same table. As it stood, expandTableLikeClause() re-did the same relation_openrv call that transformTableLikeClause() had done. However there are scenarios where this would not find the same table as expected. We hold lock on the LIKE source table, so it can't be renamed or dropped, but another table could appear before it in the search path. This explains the odd behavior reported in bug #16758 when cloning a table as a temp table of the same name. This case worked as expected before commit 502898192 introduced the need to open the source table twice, so we should fix it. To make really sure we get the same table, let's re-open it by OID not name. That requires adding an OID field to struct TableLikeClause, which is a little nervous-making from an ABI standpoint, but as long as it's at the end I don't think there's any serious risk. Per bug #16758 from Marc Boeren. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d98e27dc6e41c911277812c46664d240c3eeba0e Modified Files -- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c| 1 + src/backend/parser/gram.y | 1 + src/backend/parser/parse_utilcmd.c | 14 +++--- src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_table_like.out | 21 + src/test/regress/sql/create_table_like.sql | 8 8 files changed, 45 insertions(+), 3 deletions(-)
pgsql: pg_checksums: data_checksum_version is unsigned so use %u not %d
pg_checksums: data_checksum_version is unsigned so use %u not %d While the previous behavior didn't generate a warning, we might as well use an accurate *printf specification. Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/888671a8cda5896d36d3ec523e201ab6a11e1855 Modified Files -- src/bin/pg_checksums/pg_checksums.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: pg_checksums: data_checksum_version is unsigned so use %u not %d
pg_checksums: data_checksum_version is unsigned so use %u not %d While the previous behavior didn't generate a warning, we might as well use an accurate *printf specification. Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c50b6f7a9ca7786219646fb6b266ab6b18082aa3 Modified Files -- src/bin/pg_checksums/pg_checksums.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: pg_checksums: data_checksum_version is unsigned so use %u not %d
pg_checksums: data_checksum_version is unsigned so use %u not %d While the previous behavior didn't generate a warning, we might as well use an accurate *printf specification. Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eec90ffbf86f77102e0238b39591a26667cab0db Modified Files -- src/bin/pg_checksums/pg_checksums.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Move SHA2 routines to a new generic API layer for crypto hashes
Move SHA2 routines to a new generic API layer for crypto hashes
Two new routines to allocate a hash context and to free it are created,
as these become necessary for the goal behind this refactoring: switch
the all cryptohash implementations for OpenSSL to use EVP (for FIPS and
also because upstream does not recommend the use of low-level cryptohash
functions for 20 years). Note that OpenSSL hides the internals of
cryptohash contexts since 1.1.0, so it is necessary to leave the
allocation to OpenSSL itself, explaining the need for those two new
routines. This part is going to require more work to properly track
hash contexts with resource owners, but this not introduced here.
Still, this refactoring makes the move possible.
This reduces the number of routines for all SHA2 implementations from
twelve (SHA{224,256,386,512} with init, update and final calls) to five
(create, free, init, update and final calls) by incorporating the hash
type directly into the hash context data.
The new cryptohash routines are moved to a new file, called cryptohash.c
for the fallback implementations, with SHA2 specifics becoming a part
internal to src/common/. OpenSSL specifics are part of
cryptohash_openssl.c. This infrastructure is usable for more hash
types, like MD5 or HMAC.
Any code paths using the internal SHA2 routines are adapted to report
correctly errors, which are most of the changes of this commit. The
zones mostly impacted are checksum manifests, libpq and SCRAM.
Note that e21cbb4 was a first attempt to switch SHA2 to EVP, but it
lacked the refactoring needed for libpq, as done here.
This patch has been tested on Linux and Windows, with and without
OpenSSL, and down to 1.0.1, the oldest version supported on HEAD.
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/87ae9691d25379785f8c0f81b06a14818cfd8c56
Modified Files
--
contrib/pgcrypto/internal-sha2.c | 188 +++-
src/backend/libpq/auth-scram.c| 113 ++---
src/backend/replication/backup_manifest.c | 25 +++-
src/backend/replication/basebackup.c | 24 ++--
src/backend/utils/adt/cryptohashes.c | 53 +---
src/bin/pg_verifybackup/parse_manifest.c | 15 ++-
src/bin/pg_verifybackup/pg_verifybackup.c | 24 +++-
src/common/Makefile | 6 +-
src/common/checksum_helper.c | 79 +---
src/common/cryptohash.c | 190
src/common/cryptohash_openssl.c | 197 ++
src/common/scram-common.c | 175 ++
src/common/sha2.c | 23 +++-
src/common/sha2_int.h | 91 ++
src/common/sha2_openssl.c | 102
src/include/common/checksum_helper.h | 13 +-
src/include/common/cryptohash.h | 40 ++
src/include/common/scram-common.h | 17 +--
src/include/common/sha2.h | 89 +-
src/include/replication/backup_manifest.h | 3 +-
src/interfaces/libpq/fe-auth-scram.c | 116 ++
src/tools/msvc/Mkvcbuild.pm | 3 +-
src/tools/pgindent/typedefs.list | 2 +
23 files changed, 1039 insertions(+), 549 deletions(-)
pgsql: Allow restore_command parameter to be changed with reload.
Allow restore_command parameter to be changed with reload. This commit changes restore_command from PGC_POSTMASTER to PGC_SIGHUP. As the side effect of this commit, restore_command can be reset to empty during archive recovery. In this setting, archive recovery tries to replay only WAL files available in pg_wal directory. This is the same behavior as when the command that always fails is specified in restore_command. Note that restore_command still must be specified (not empty) when starting archive recovery, even after applying this commit. This is necessary as the safeguard to prevent users from forgetting to specify restore_command and starting archive recovery. Thanks to Peter Eisentraut, Michael Paquier, Andres Freund, Robert Haas and Anastasia Lubennikova for discussion. Author: Sergei Kornilov Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/942305a36365433eff3c1937945758f2dbf1662b Modified Files -- doc/src/sgml/config.sgml | 3 ++- src/backend/utils/misc/guc.c | 2 +- src/backend/utils/misc/postgresql.conf.sample | 1 - 3 files changed, 3 insertions(+), 3 deletions(-)
Re: pgsql: Move SHA2 routines to a new generic API layer for crypto hashes
On 2020/12/02 10:41, Michael Paquier wrote:
Move SHA2 routines to a new generic API layer for crypto hashes
Thanks for improving this!
I got the following compiler failure. ISTM that the variable "status"
in both pg_cryptohash_update() and pg_cryptohash_final() needs
to be initialized with 0. Patch attached. Thought?
cryptohash_openssl.c: In function ‘pg_cryptohash_update’:
cryptohash_openssl.c:144:5: error: ‘status’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
if (status <= 0)
^
cryptohash_openssl.c: In function ‘pg_cryptohash_final’:
cryptohash_openssl.c:179:5: error: ‘status’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
if (status <= 0)
^
cc1: all warnings being treated as errors
make[2]: *** [cryptohash_openssl.o] Error 1
: recipe for target 'cryptohash_openssl.o' failed
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/common/cryptohash_openssl.c b/src/common/cryptohash_openssl.c
index 8e2c69b48b..33f17cac33 100644
--- a/src/common/cryptohash_openssl.c
+++ b/src/common/cryptohash_openssl.c
@@ -119,7 +119,7 @@ pg_cryptohash_init(pg_cryptohash_ctx *ctx)
int
pg_cryptohash_update(pg_cryptohash_ctx *ctx, const uint8 *data, size_t len)
{
- int status;
+ int status = 0;
if (ctx == NULL)
return 0;
@@ -154,7 +154,7 @@ pg_cryptohash_update(pg_cryptohash_ctx *ctx, const uint8
*data, size_t len)
int
pg_cryptohash_final(pg_cryptohash_ctx *ctx, uint8 *dest)
{
- int status;
+ int status = 0;
if (ctx == NULL)
return 0;
Re: pgsql: Move SHA2 routines to a new generic API layer for crypto hashes
On Wed, Dec 02, 2020 at 11:42:58AM +0900, Fujii Masao wrote: > On 2020/12/02 10:41, Michael Paquier wrote: >> Move SHA2 routines to a new generic API layer for crypto hashes > > Thanks for improving this! > I got the following compiler failure. ISTM that the variable "status" > in both pg_cryptohash_update() and pg_cryptohash_final() needs > to be initialized with 0. Patch attached. Thought? Neither gcc nor clang complain on my end, even with -Werror=maybe-uninitialized, because they understand that the status will be set anyway as we have no default in the switch? :) You are right, this is bad practice for those code paths, so let's fix it. Which version are you using? I'd like to be able to reproduce that and double-check if there are more missing spots. -- Michael signature.asc Description: PGP signature
Re: pgsql: Move SHA2 routines to a new generic API layer for crypto hashes
On Wed, Dec 02, 2020 at 12:14:33PM +0900, Michael Paquier wrote: > Neither gcc nor clang complain on my end, even with > -Werror=maybe-uninitialized, because they understand that the status > will be set anyway as we have no default in the switch? :) > > You are right, this is bad practice for those code paths, so let's fix > it. Which version are you using? I'd like to be able to reproduce > that and double-check if there are more missing spots. Hmm. Forget that. I can see the warnings once I switched to -O2, which is what I guess you are doing. Some animals are also showing that. I'll fix in a minute. Thanks for the report! -- Michael signature.asc Description: PGP signature
pgsql: Fix compilation warnings in cryptohash_openssl.c
Fix compilation warnings in cryptohash_openssl.c These showed up with -O2. Oversight in 87ae969. Author: Fujii Masao Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/91624c2ff8809145880383b0fa84be0ee98f55b5 Modified Files -- src/common/cryptohash_openssl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: pgsql: Move SHA2 routines to a new generic API layer for crypto hashes
On 2020/12/02 12:21, Michael Paquier wrote: On Wed, Dec 02, 2020 at 12:14:33PM +0900, Michael Paquier wrote: Neither gcc nor clang complain on my end, even with -Werror=maybe-uninitialized, because they understand that the status will be set anyway as we have no default in the switch? :) You are right, this is bad practice for those code paths, so let's fix it. Which version are you using? I'd like to be able to reproduce that and double-check if there are more missing spots. Hmm. Forget that. I can see the warnings once I switched to -O2, which is what I guess you are doing. Some animals are also showing that. I'll fix in a minute. Thanks for the report! Thanks! FWIW, I got that failure when I built PostgreSQL in github actions using yml file [1]. The default setting -O2 is used there. Since -Werror is used, I got the compiler failure than warning. [1] https://github.com/MasaoFujii/my-bin/blob/master/data/build.yml Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
pgsql: Track total number of WAL records, FPIs and bytes generated in t
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] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01469241b2ff6f17fc0b3f20f01559145ffab29e Modified Files -- doc/src/sgml/monitoring.sgml | 27 + src/backend/catalog/system_views.sql | 3 +++ src/backend/postmaster/pgstat.c | 38 src/backend/utils/adt/pgstatfuncs.c | 27 - src/include/catalog/pg_proc.dat | 5 +++-- src/include/pgstat.h | 6 ++ src/test/regress/expected/rules.out | 7 +-- 7 files changed, 104 insertions(+), 9 deletions(-)
