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
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/mes
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-c
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-c
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-c
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-c
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 tab
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 tab
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 tab
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 tab
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 tab
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 tab
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 tab
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/888671a8cda5896d36d
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/c50b6f7a9ca7
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/eec90ffbf86f
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 upstre
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 avai
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.
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_cryptoha
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 th
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/91624c2ff8809
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? :)
Yo
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.
24 matches
Mail list logo
