pgsql: Add pg_nodiscard function declaration specifier

2020-11-11 Thread Peter Eisentraut
Add pg_nodiscard function declaration specifier

pg_nodiscard means the compiler should warn if the result of a
function call is ignored.  The name "nodiscard" is chosen in alignment
with (possibly future) C and C++ standards.  It maps to the GCC
attribute warn_unused_result.

Reviewed-by: Michael Paquier 
Discussion: 
https://www.postgresql.org/message-id/flat/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/c617aea6acdd9057a14d91ff294905b1b5509348

Modified Files
--
src/include/c.h | 12 
1 file changed, 12 insertions(+)



pgsql: Add pg_nodiscard decorations to some functions

2020-11-11 Thread Peter Eisentraut
Add pg_nodiscard decorations to some functions

Especially for the list API such as lappend() forgetting to assign the
return value is a common problem.

Reviewed-by: Michael Paquier 
Discussion: 
https://www.postgresql.org/message-id/flat/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/a378ba49a5cfec073d885f4943e1c7e4b83abd3b

Modified Files
--
src/include/nodes/pg_list.h | 62 ++---
src/include/utils/palloc.h  |  4 +--
2 files changed, 33 insertions(+), 33 deletions(-)



Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-11 Thread Andrew Dunstan


On 11/10/20 3:31 PM, Tom Lane wrote:
> Andrew Dunstan  writes:
>> On 11/9/20 5:41 PM, Tom Lane wrote:
>>> What I have in mind to apply to 9.5 through 13 is per attached.
>> You also need to modify first_el_agg_any.
> ... doh.  That one is a little messier because there's no equally useful
> substitute function.  What I'm inclined to do for that is to add a
> SQL-language wrapper to reproduce the old signature for array_append.
> As attached.  (I'm keeping this separate from the other patch, since
> this doesn't go back as far.)
>
>

Seems reasonable.


cheers


andrew





pgsql: Remove vacuumdb --analyze-in-stages from pg_upgrade tests

2020-11-11 Thread Magnus Hagander
Remove vacuumdb --analyze-in-stages from pg_upgrade tests

This step was only there to test the script when we generated those, but
commit 8f113698b6 removed those scripts, so it's not needed anymore.

Reported-By: Peter Eisentraut
Discussion: 
https://postgr.es/m/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1e12a495b4749c7dc8e38e347554f2b24297f4ba

Modified Files
--
src/bin/pg_upgrade/test.sh  | 2 --
src/tools/msvc/vcregress.pl | 2 --
2 files changed, 4 deletions(-)



pgsql: Remove line missed in previous commit

2020-11-11 Thread Magnus Hagander
Remove line missed in previous commit

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/4e3ffd5981536f93787ae6d81bc179da0acc423e

Modified Files
--
src/tools/msvc/vcregress.pl | 1 -
1 file changed, 1 deletion(-)



pgsql: Fix some stray whitespace in parser files

2020-11-11 Thread Peter Eisentraut
Fix some stray whitespace in parser files

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/0af302af40669d9bc6de7a202e4723fee39d9376

Modified Files
--
src/backend/bootstrap/bootscanner.l  |  2 +-
src/backend/parser/gram.y| 18 
src/backend/utils/adt/jsonpath_gram.y|  6 +++---
src/interfaces/ecpg/preproc/ecpg.trailer | 36 
4 files changed, 31 insertions(+), 31 deletions(-)



pgsql: Remove duplicate code in brin_memtuple_initialize

2020-11-11 Thread Tomas Vondra
Remove duplicate code in brin_memtuple_initialize

Commit 8bf74967dab moved some of the code from brin_new_memtuple to
brin_memtuple_initialize, but this resulted in some of the code being
duplicate. Fix by removing the duplicate lines and backpatch to 10.

Author: Tomas Vondra
Backpatch-through: 10
Discussion: 
https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/42c63ab6e2c39c2fbfc70fa659b0cf5692178b77

Modified Files
--
src/backend/access/brin/brin_tuple.c | 3 ---
1 file changed, 3 deletions(-)



pgsql: Remove duplicate code in brin_memtuple_initialize

2020-11-11 Thread Tomas Vondra
Remove duplicate code in brin_memtuple_initialize

Commit 8bf74967dab moved some of the code from brin_new_memtuple to
brin_memtuple_initialize, but this resulted in some of the code being
duplicate. Fix by removing the duplicate lines and backpatch to 10.

Author: Tomas Vondra
Backpatch-through: 10
Discussion: 
https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/c885e4a2f93cff543a7e0ccaaf82b8148fc53401

Modified Files
--
src/backend/access/brin/brin_tuple.c | 3 ---
1 file changed, 3 deletions(-)



pgsql: Remove duplicate code in brin_memtuple_initialize

2020-11-11 Thread Tomas Vondra
Remove duplicate code in brin_memtuple_initialize

Commit 8bf74967dab moved some of the code from brin_new_memtuple to
brin_memtuple_initialize, but this resulted in some of the code being
duplicate. Fix by removing the duplicate lines and backpatch to 10.

Author: Tomas Vondra
Backpatch-through: 10
Discussion: 
https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/1186a9d65d9953033417d22840893acfe48d6d20

Modified Files
--
src/backend/access/brin/brin_tuple.c | 3 ---
1 file changed, 3 deletions(-)



pgsql: Remove duplicate code in brin_memtuple_initialize

2020-11-11 Thread Tomas Vondra
Remove duplicate code in brin_memtuple_initialize

Commit 8bf74967dab moved some of the code from brin_new_memtuple to
brin_memtuple_initialize, but this resulted in some of the code being
duplicate. Fix by removing the duplicate lines and backpatch to 10.

Author: Tomas Vondra
Backpatch-through: 10
Discussion: 
https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com

Branch
--
REL_12_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/0d0626e27d56a52f78cd71a796ee2e8fe216f217

Modified Files
--
src/backend/access/brin/brin_tuple.c | 3 ---
1 file changed, 3 deletions(-)



pgsql: Remove duplicate code in brin_memtuple_initialize

2020-11-11 Thread Tomas Vondra
Remove duplicate code in brin_memtuple_initialize

Commit 8bf74967dab moved some of the code from brin_new_memtuple to
brin_memtuple_initialize, but this resulted in some of the code being
duplicate. Fix by removing the duplicate lines and backpatch to 10.

Author: Tomas Vondra
Backpatch-through: 10
Discussion: 
https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com

Branch
--
REL_11_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/c4424d33cca9719ae925d0cc018acf32182a6d95

Modified Files
--
src/backend/access/brin/brin_tuple.c | 3 ---
1 file changed, 3 deletions(-)



pgsql: Remove useless SHA256 initialization when not using backup manif

2020-11-11 Thread Michael Paquier
Remove useless SHA256 initialization when not using backup manifests

Attempting to take a base backup with Postgres linking to a build of
OpenSSL with FIPS enabled currently fails with or even without a backup
manifest requested because of this mandatory SHA256 initialization used
for the manifest file itself.  However, there is no need to do this
initialization at all if backup manifests are not needed because there
is no data to append to the manifest.

Note that being able to use backup manifests with OpenSSL+FIPS requires
a switch of the SHA2 implementation to use EVP, which would cause an ABI
breakage so this cannot be backpatched to 13 as it has been already
released, but at least avoiding this SHA256 initialization gives users
the possibility to take a base backup even when specifying --no-manifest
with pg_basebackup.

Author: Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 13

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/9a94b925317ec963befffaa7e5edc38a62c2b88f

Modified Files
--
src/backend/replication/backup_manifest.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)



pgsql: Remove useless SHA256 initialization when not using backup manif

2020-11-11 Thread Michael Paquier
Remove useless SHA256 initialization when not using backup manifests

Attempting to take a base backup with Postgres linking to a build of
OpenSSL with FIPS enabled currently fails with or even without a backup
manifest requested because of this mandatory SHA256 initialization used
for the manifest file itself.  However, there is no need to do this
initialization at all if backup manifests are not needed because there
is no data to append to the manifest.

Note that being able to use backup manifests with OpenSSL+FIPS requires
a switch of the SHA2 implementation to use EVP, which would cause an ABI
breakage so this cannot be backpatched to 13 as it has been already
released, but at least avoiding this SHA256 initialization gives users
the possibility to take a base backup even when specifying --no-manifest
with pg_basebackup.

Author: Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 13

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/03f9cd93eaa5e3385b075bb1a17d2adde3e23edd

Modified Files
--
src/backend/replication/backup_manifest.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)



pgsql: pg_stat_statements: track number of rows processed by REFRESH MA

2020-11-11 Thread Fujii Masao
pg_stat_statements: track number of rows processed by REFRESH MATERIALIZED VIEW.

Commit 6023b7ea71 allowed pg_stat_statements to track the number
of rows retrieved or affected by some utility commands including
CREATE MATERIALIZED VIEW. However it did not track the rowcount
of REFRESH MATERIALIZED VIEW. This commit allows pg_stat_statements
to track that.

To track that, this commit changes the query completion for
REFRESH MATERIALIZED VIEW so that it saves the rowcount. But note that
the rowcount is still not displayed in the command completion tag output.
That is, the display_rowcount flag of CMDTAG_REFRESH_MATERIALIZED_VIEW
command tag is left false in cmdtaglist.h. Otherwise, the change of
completion tag output might break applications using it.

Author: Katsuragi Yuta, Seino Yuki
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/[email protected]
Discussion: 
https://postgr.es/m/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/b62e6056a05c60ce9edf93e87e1487ae50245a04

Modified Files
--
contrib/pg_stat_statements/expected/pg_stat_statements.out |  8 +---
contrib/pg_stat_statements/pg_stat_statements.c|  9 +
contrib/pg_stat_statements/sql/pg_stat_statements.sql  |  5 +++--
src/backend/commands/matview.c | 11 +++
4 files changed, 24 insertions(+), 9 deletions(-)



pgsql: Fix name of the macro for getting signature length trgm_gist.c

2020-11-11 Thread Alexander Korotkov
Fix name of the macro for getting signature length trgm_gist.c

911e702077 has introduced the opclass parameters including signature length
for a set of GiST opclasses.  Due to copy-pasting, macro for getting the
signature length in trgm_gist.c was named LTREE_GET_ASIGLEN().  Fix that by
renaming this macro to just GET_SIGLEN().

Backpatch-through: 13

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/065683bbdbab7fe51c59a479f4136328577bbecd

Modified Files
--
contrib/pg_trgm/trgm_gist.c | 16 
1 file changed, 8 insertions(+), 8 deletions(-)



pgsql: Fix name of the macro for getting signature length trgm_gist.c

2020-11-11 Thread Alexander Korotkov
Fix name of the macro for getting signature length trgm_gist.c

911e702077 has introduced the opclass parameters including signature length
for a set of GiST opclasses.  Due to copy-pasting, macro for getting the
signature length in trgm_gist.c was named LTREE_GET_ASIGLEN().  Fix that by
renaming this macro to just GET_SIGLEN().

Backpatch-through: 13

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/8ca8208ace4e67a9149946814d35d7cf18ff60d0

Modified Files
--
contrib/pg_trgm/trgm_gist.c | 16 
1 file changed, 8 insertions(+), 8 deletions(-)



pgsql: Use standard SIGHUP and SIGTERM handlers in walreceiver.

2020-11-11 Thread Fujii Masao
Use standard SIGHUP and SIGTERM handlers in walreceiver.

Commit 1e53fe0e70 changed background processes so that they use
standard SIGHUP handler. Like that, this commit makes walreceiver
use standard SIGHUP and SIGTERM handlers, to simplify the code.

As the side effect of this commit, walreceiver can wake up and process
the configuration files promptly when receiving SIGHUP. Because the
standard SIGHUP handler sets the latch. On the other hand, previously
there could be a time lag between the receipt of SIGHUP and
the process of configuration files since the dedicated handler didn't
set the latch.

Author: Bharath Rupireddy, tweaked by Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Fujii Masao
Discussion: 
https://postgr.es/m/calj2acxporuqepswdtoem_s82v9rw32e1fymopz5nue+twk...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1a2ae7c50fb4ab17a8d38e755fc871ebc3a5845d

Modified Files
--
src/backend/replication/walreceiver.c | 53 +++
1 file changed, 10 insertions(+), 43 deletions(-)



pgsql: Fix typo in contrib/pg_trgm/pg_trgm--1.4--1.5.sql

2020-11-11 Thread Alexander Korotkov
Fix typo in contrib/pg_trgm/pg_trgm--1.4--1.5.sql

Backpatch-through: 13

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/3e8ec5b1408a15fb41cada2635163a598d8607d1

Modified Files
--
contrib/pg_trgm/pg_trgm--1.4--1.5.sql | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)



pgsql: Fix typo in contrib/pg_trgm/pg_trgm--1.4--1.5.sql

2020-11-11 Thread Alexander Korotkov
Fix typo in contrib/pg_trgm/pg_trgm--1.4--1.5.sql

Backpatch-through: 13

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/6058f22324c8781b1914551ab4da431224c3a7dd

Modified Files
--
contrib/pg_trgm/pg_trgm--1.4--1.5.sql | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)



pgsql: Clean up optional rules in grammar

2020-11-11 Thread Peter Eisentraut
Clean up optional rules in grammar

Various rules for optional keywords contained unnecessary rules and
type declarations.  Remove those, thus making the output a tiny bit
smaller.

Reviewed-by: Heikki Linnakangas 
Discussion: 
https://www.postgresql.org/message-id/flat/e9eed669-e32d-6919-fed4-acc0daea857b%40enterprisedb.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1b2b19f7584b7c0025aa40862cd38c79d340be7d

Modified Files
--
src/backend/parser/gram.y | 80 +++
1 file changed, 40 insertions(+), 40 deletions(-)