pgsql: Add error code for encryption failure in pgcrypto

2020-11-01 Thread Michael Paquier
Add error code for encryption failure in pgcrypto

PXE_DECRYPT_FAILED exists already for decryption errors, and an
equivalent for encryption did not exist.  There is one code path that
deals with such failures for OpenSSL but it used PXE_ERR_GENERIC, which
was inconsistent.  This switches this code path to use the new error
PXE_ENCRYPT_FAILED instead of PXE_ERR_GENERIC, making the code used for
encryption more consistent with the decryption.

Author: Daniel Gustafsson
Discussion: https://postgr.es/m/[email protected]

Branch
--
master

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

Modified Files
--
contrib/pgcrypto/openssl.c | 2 +-
contrib/pgcrypto/px.c  | 1 +
contrib/pgcrypto/px.h  | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)



pgsql: Preserve index data in pg_statistic across REINDEX CONCURRENTLY

2020-11-01 Thread Michael Paquier
Preserve index data in pg_statistic across REINDEX CONCURRENTLY

Statistics associated to an index got lost after running REINDEX
CONCURRENTLY, while the non-concurrent case preserves these correctly.
The concurrent and non-concurrent operations need to be consistent for
the end-user, and missing statistics would force to wait for a new
analyze to happen, which could take some time depending on the activity
of the existing autovacuum workers.  This issue is fixed by copying any
existing entries in pg_statistic associated to the old index to the new
one.  Note that this copy is already done with the data of the index in
the stats collector.

Reported-by: Fabrízio de Royes Mello
Author: Michael Paquier, Fabrízio de Royes Mello
Reviewed-by: Justin Pryzby
Discussion: 
https://postgr.es/m/cafcns+qpfpmihd1otxvcpdvahicjda9qbusujgahumjyumb...@mail.gmail.com
Backpatch-through: 12

Branch
--
REL_12_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/41a033b5054e047cc67a92e17fbbe4accb658b3b

Modified Files
--
src/backend/catalog/heap.c | 41 ++
src/backend/catalog/index.c|  3 +++
src/include/catalog/heap.h |  1 +
src/test/regress/expected/create_index.out | 22 
src/test/regress/sql/create_index.sql  | 12 +
5 files changed, 79 insertions(+)



pgsql: Preserve index data in pg_statistic across REINDEX CONCURRENTLY

2020-11-01 Thread Michael Paquier
Preserve index data in pg_statistic across REINDEX CONCURRENTLY

Statistics associated to an index got lost after running REINDEX
CONCURRENTLY, while the non-concurrent case preserves these correctly.
The concurrent and non-concurrent operations need to be consistent for
the end-user, and missing statistics would force to wait for a new
analyze to happen, which could take some time depending on the activity
of the existing autovacuum workers.  This issue is fixed by copying any
existing entries in pg_statistic associated to the old index to the new
one.  Note that this copy is already done with the data of the index in
the stats collector.

Reported-by: Fabrízio de Royes Mello
Author: Michael Paquier, Fabrízio de Royes Mello
Reviewed-by: Justin Pryzby
Discussion: 
https://postgr.es/m/cafcns+qpfpmihd1otxvcpdvahicjda9qbusujgahumjyumb...@mail.gmail.com
Backpatch-through: 12

Branch
--
master

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

Modified Files
--
src/backend/catalog/heap.c | 41 ++
src/backend/catalog/index.c|  3 +++
src/include/catalog/heap.h |  1 +
src/test/regress/expected/create_index.out | 22 
src/test/regress/sql/create_index.sql  | 12 +
5 files changed, 79 insertions(+)



pgsql: Preserve index data in pg_statistic across REINDEX CONCURRENTLY

2020-11-01 Thread Michael Paquier
Preserve index data in pg_statistic across REINDEX CONCURRENTLY

Statistics associated to an index got lost after running REINDEX
CONCURRENTLY, while the non-concurrent case preserves these correctly.
The concurrent and non-concurrent operations need to be consistent for
the end-user, and missing statistics would force to wait for a new
analyze to happen, which could take some time depending on the activity
of the existing autovacuum workers.  This issue is fixed by copying any
existing entries in pg_statistic associated to the old index to the new
one.  Note that this copy is already done with the data of the index in
the stats collector.

Reported-by: Fabrízio de Royes Mello
Author: Michael Paquier, Fabrízio de Royes Mello
Reviewed-by: Justin Pryzby
Discussion: 
https://postgr.es/m/cafcns+qpfpmihd1otxvcpdvahicjda9qbusujgahumjyumb...@mail.gmail.com
Backpatch-through: 12

Branch
--
REL_13_STABLE

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

Modified Files
--
src/backend/catalog/heap.c | 41 ++
src/backend/catalog/index.c|  3 +++
src/include/catalog/heap.h |  1 +
src/test/regress/expected/create_index.out | 22 
src/test/regress/sql/create_index.sql  | 12 +
5 files changed, 79 insertions(+)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/7f4235032f0d75ea1ad29b192d57fee3d8fe533e

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
REL_10_STABLE

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

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
REL_11_STABLE

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

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/1127377a578bde76ed09edd7cd5d8965365c8aaa

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/0041941f5bbe48ff3a05942efc6aa65f4f389efc

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
REL_12_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/7d72fd9e6db686c9a499d4238d23525437adc132

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Avoid null pointer dereference if error result lacks SQLSTATE.

2020-11-01 Thread Tom Lane
Avoid null pointer dereference if error result lacks SQLSTATE.

Although error results received from the backend should always have
a SQLSTATE field, ones generated by libpq won't, making this code
vulnerable to a crash after, say, untimely loss of connection.
Noted by Coverity.

Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/29ae4cd82949843d09aa02a8125a5b5087201431

Modified Files
--
src/bin/pg_dump/pg_backup_db.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)



pgsql: Fix two issues in TOAST decompression.

2020-11-01 Thread Tom Lane
Fix two issues in TOAST decompression.

pglz_maximum_compressed_size() potentially underestimated the amount
of compressed data required to produce N bytes of decompressed data;
this is a fault in commit 11a078cf8.

Separately from that, pglz_decompress() failed to protect itself
against corrupt compressed data, particularly off == 0 in a match
tag.  Commit c60e520f6 turned such a situation into an infinite loop,
where before it'd just have resulted in garbage output.

The combination of these two bugs seems like it may explain bug #16694
from Tom Vijlbrief, though it's impossible to be quite sure without
direct inspection of the failing session.  (One needs to assume that
the pglz_maximum_compressed_size() bug caused us to fail to fetch the
second byte of a match tag, and what happened to be there instead was
a zero.  The reported infinite loop is hard to explain without off == 0,
though.)

Aside from fixing the bugs, rewrite associated comments for more
clarity.

Back-patch to v13 where both these commits landed.

Discussion: https://postgr.es/m/[email protected]

Branch
--
master

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

Modified Files
--
src/common/pg_lzcompress.c | 101 +
1 file changed, 66 insertions(+), 35 deletions(-)



pgsql: Fix two issues in TOAST decompression.

2020-11-01 Thread Tom Lane
Fix two issues in TOAST decompression.

pglz_maximum_compressed_size() potentially underestimated the amount
of compressed data required to produce N bytes of decompressed data;
this is a fault in commit 11a078cf8.

Separately from that, pglz_decompress() failed to protect itself
against corrupt compressed data, particularly off == 0 in a match
tag.  Commit c60e520f6 turned such a situation into an infinite loop,
where before it'd just have resulted in garbage output.

The combination of these two bugs seems like it may explain bug #16694
from Tom Vijlbrief, though it's impossible to be quite sure without
direct inspection of the failing session.  (One needs to assume that
the pglz_maximum_compressed_size() bug caused us to fail to fetch the
second byte of a match tag, and what happened to be there instead was
a zero.  The reported infinite loop is hard to explain without off == 0,
though.)

Aside from fixing the bugs, rewrite associated comments for more
clarity.

Back-patch to v13 where both these commits landed.

Discussion: https://postgr.es/m/[email protected]

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/2330f4d3a87ac43b6ecd31bfd698384888ed03cb

Modified Files
--
src/common/pg_lzcompress.c | 101 +
1 file changed, 66 insertions(+), 35 deletions(-)



pgsql: Allow run-time pruning on nested Append/MergeAppend nodes

2020-11-01 Thread David Rowley
Allow run-time pruning on nested Append/MergeAppend nodes

Previously we only tagged on the required information to allow the
executor to perform run-time partition pruning for Append/MergeAppend
nodes belonging to base relations.  It was thought that nested
Append/MergeAppend nodes were just about always pulled up into the
top-level Append/MergeAppend and that making the run-time pruning info for
any sub Append/MergeAppend nodes was a waste of time.  However, that was
likely badly thought through.

Some examples of cases we're unable to pullup nested Append/MergeAppends
are: 1) Parallel Append nodes with a mix of parallel and non-parallel
paths into a Parallel Append.  2) When planning an ordered Append scan a
sub-partition which is unordered may require a nested MergeAppend path to
ensure sub-partitions don't mix up the order of tuples being fed into the
top-level Append.

Unfortunately, it was not just as simple as removing the lines in
createplan.c which were purposefully not building the run-time pruning
info for anything but RELOPT_BASEREL relations.  The code in
add_paths_to_append_rel() was far too sloppy about which partitioned_rels
it included for the Append/MergeAppend paths.  The original code there
would always assume accumulate_append_subpath() would pull each sub-Append
and sub-MergeAppend path into the top-level path.  While it does not
appear that there were any actual bugs caused by having the additional
partitioned table RT indexes recorded, what it did mean is that later in
planning, when we built the run-time pruning info that we wasted effort
and built PartitionedRelPruneInfos for partitioned tables that we had no
subpaths for the executor to run-time prune.

Here we tighten that up so that partitioned_rels only ever contains the RT
index for partitioned tables which actually have subpaths in the given
Append/MergeAppend.  We can now Assert that every PartitionedRelPruneInfo
has a non-empty present_parts.  That should allow us to catch any weird
corner cases that have been missed.

In passing, it seems there is no longer a good reason to have the
AppendPath and MergeAppendPath's partitioned_rel fields a List of IntList.
We can simply have a List of Relids instead.  This is more compact in
memory and faster to add new members to.  We still know which is the root
level partition as these always have a lower relid than their children.
Previously this field was used for more things, but run-time partition
pruning now remains the only user of it and it has no need for a List of
IntLists.

Here we also get rid of the RelOptInfo partitioned_child_rels field. This
is what was previously used to (sometimes incorrectly) set the
Append/MergeAppend path's partitioned_rels field.  That was the only usage
of that field, so we can happily just remove it.

I also couldn't resist changing some nearby code to make use of the newly
added for_each_from macro so we can skip the first element in the list
without checking if the current item was the first one on each
iteration.

A bug report from Andreas Kretschmer prompted all this work, however,
after some consideration, I'm not personally classing this as a bug fix.
So no backpatch.  In Andreas' test case, it just wasn't that clear that
there was a nested Append since the top-level Append just had a single
sub-path which was pulled up a level, per 8edd0e794.

Author: David Rowley
Reviewed-by: Amit Langote
Discussion: 
https://postgr.es/m/flat/CAApHDvqSchs%2BubdybcfFaSPB%2B%2BEA7kqMaoqajtP0GtZvzOOR3g%40mail.gmail.com

Branch
--
master

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

Modified Files
--
src/backend/nodes/outfuncs.c  |   1 -
src/backend/optimizer/path/allpaths.c | 234 --
src/backend/optimizer/plan/createplan.c   |   2 -
src/backend/optimizer/util/relnode.c  |   3 -
src/backend/partitioning/partprune.c  |  29 ++--
src/include/nodes/pathnodes.h |  14 +-
src/test/regress/expected/partition_prune.out | 102 +++
src/test/regress/sql/partition_prune.sql  |  49 ++
8 files changed, 319 insertions(+), 115 deletions(-)



pgsql: Extend PageIsVerified() to handle more custom options

2020-11-01 Thread Michael Paquier
Extend PageIsVerified() to handle more custom options

This is useful for checks of relation pages without having to load the
pages into the shared buffers, and two cases can make use of that: page
verification in base backups and the online, lock-safe, flavor.

Compatibility is kept with past versions using a routine that calls the
new extended routine with the set of options compatible with the
original version.  Contrary to d401c576, a macro cannot be used as there
may be external code relying on the presence of the original routine.

This is applied down to 11, where this will be used by a follow-up
commit addressing a set of issues with page verification in base
backups.

Extracted from a larger patch by the same author.

Author: Anastasia Lubennikova
Reviewed-by: Michael Paquier, Julien Rouhaud
Discussion: 
https://postgr.es/m/[email protected]
Backpatch-through: 11

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/017e78a3edc261143c7d791cafca5a5ad326a679

Modified Files
--
src/backend/catalog/storage.c   |  3 ++-
src/backend/storage/buffer/bufmgr.c |  6 --
src/backend/storage/page/bufpage.c  | 32 ++--
src/include/storage/bufpage.h   | 17 -
4 files changed, 44 insertions(+), 14 deletions(-)



pgsql: Extend PageIsVerified() to handle more custom options

2020-11-01 Thread Michael Paquier
Extend PageIsVerified() to handle more custom options

This is useful for checks of relation pages without having to load the
pages into the shared buffers, and two cases can make use of that: page
verification in base backups and the online, lock-safe, flavor.

Compatibility is kept with past versions using a routine that calls the
new extended routine with the set of options compatible with the
original version.  Contrary to d401c576, a macro cannot be used as there
may be external code relying on the presence of the original routine.

This is applied down to 11, where this will be used by a follow-up
commit addressing a set of issues with page verification in base
backups.

Extracted from a larger patch by the same author.

Author: Anastasia Lubennikova
Reviewed-by: Michael Paquier, Julien Rouhaud
Discussion: 
https://postgr.es/m/[email protected]
Backpatch-through: 11

Branch
--
REL_12_STABLE

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

Modified Files
--
src/backend/catalog/storage.c   |  3 ++-
src/backend/storage/buffer/bufmgr.c |  6 --
src/backend/storage/page/bufpage.c  | 32 ++--
src/include/storage/bufpage.h   |  7 +++
4 files changed, 39 insertions(+), 9 deletions(-)



pgsql: Extend PageIsVerified() to handle more custom options

2020-11-01 Thread Michael Paquier
Extend PageIsVerified() to handle more custom options

This is useful for checks of relation pages without having to load the
pages into the shared buffers, and two cases can make use of that: page
verification in base backups and the online, lock-safe, flavor.

Compatibility is kept with past versions using a routine that calls the
new extended routine with the set of options compatible with the
original version.  Contrary to d401c576, a macro cannot be used as there
may be external code relying on the presence of the original routine.

This is applied down to 11, where this will be used by a follow-up
commit addressing a set of issues with page verification in base
backups.

Extracted from a larger patch by the same author.

Author: Anastasia Lubennikova
Reviewed-by: Michael Paquier, Julien Rouhaud
Discussion: 
https://postgr.es/m/[email protected]
Backpatch-through: 11

Branch
--
REL_11_STABLE

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

Modified Files
--
src/backend/storage/buffer/bufmgr.c |  6 --
src/backend/storage/page/bufpage.c  | 25 -
src/include/storage/bufpage.h   |  6 ++
3 files changed, 30 insertions(+), 7 deletions(-)



pgsql: Use Enum for top level logical replication message types.

2020-11-01 Thread Amit Kapila
Use Enum for top level logical replication message types.

Logical replication protocol uses a single byte character to identify a
message type in logical replication protocol. The code uses string
literals for the same. Use Enum so that

1. All the string literals used can be found at a single place. This
makes it easy to add more types without the risk of conflicts.

2. It's easy to locate the code handling a given message type.

3. When used with switch statements, it is easy to identify the missing
cases using -Wswitch.

Author: Ashutosh Bapat
Reviewed-by: Kyotaro Horiguchi, Andres Freund, Peter Smith and Amit Kapila
Discussion: 
https://postgr.es/m/caexhw5upzq7l0oad_enyvaiymopgkraojpe+zy5-obdcvt6...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/644f0d7cc9c2cb270746f2024c706554e0fbec82

Modified Files
--
src/backend/replication/logical/proto.c  | 26 +-
src/backend/replication/logical/worker.c | 87 
src/include/replication/logicalproto.h   | 27 ++
3 files changed, 83 insertions(+), 57 deletions(-)



pgsql: Fix some grammar and typos in comments and docs

2020-11-01 Thread Michael Paquier
Fix some grammar and typos in comments and docs

The documentation fixes are backpatched down to where they apply.

Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/796885a0713374f7bdcc3edec136e0527fcafafa

Modified Files
--
doc/src/sgml/auto-explain.sgml  | 2 +-
doc/src/sgml/ddl.sgml   | 2 +-
doc/src/sgml/ref/pg_rewind.sgml | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)



pgsql: Fix some grammar and typos in comments and docs

2020-11-01 Thread Michael Paquier
Fix some grammar and typos in comments and docs

The documentation fixes are backpatched down to where they apply.

Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6

Branch
--
REL_11_STABLE

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

Modified Files
--
doc/src/sgml/ddl.sgml   | 2 +-
doc/src/sgml/ref/pg_rewind.sgml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



pgsql: Fix some grammar and typos in comments and docs

2020-11-01 Thread Michael Paquier
Fix some grammar and typos in comments and docs

The documentation fixes are backpatched down to where they apply.

Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6

Branch
--
REL_10_STABLE

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

Modified Files
--
doc/src/sgml/ddl.sgml   | 2 +-
doc/src/sgml/ref/pg_rewind.sgml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



pgsql: Fix some grammar and typos in comments and docs

2020-11-01 Thread Michael Paquier
Fix some grammar and typos in comments and docs

The documentation fixes are backpatched down to where they apply.

Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6

Branch
--
REL9_6_STABLE

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

Modified Files
--
doc/src/sgml/ref/pg_rewind.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)



pgsql: Fix some grammar and typos in comments and docs

2020-11-01 Thread Michael Paquier
Fix some grammar and typos in comments and docs

The documentation fixes are backpatched down to where they apply.

Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6

Branch
--
REL_12_STABLE

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

Modified Files
--
doc/src/sgml/auto-explain.sgml  | 2 +-
doc/src/sgml/ddl.sgml   | 2 +-
doc/src/sgml/ref/pg_rewind.sgml | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)



pgsql: Fix some grammar and typos in comments and docs

2020-11-01 Thread Michael Paquier
Fix some grammar and typos in comments and docs

The documentation fixes are backpatched down to where they apply.

Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6

Branch
--
master

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

Modified Files
--
contrib/amcheck/verify_heapam.c  | 4 ++--
contrib/pgcrypto/pgp-compress.c  | 2 +-
doc/src/sgml/auto-explain.sgml   | 2 +-
doc/src/sgml/ddl.sgml| 2 +-
doc/src/sgml/ref/pg_rewind.sgml  | 2 +-
src/backend/access/heap/pruneheap.c  | 2 +-
src/backend/catalog/namespace.c  | 2 +-
src/backend/catalog/pg_namespace.c   | 2 +-
src/backend/commands/copy.c  | 6 +++---
src/backend/commands/tablecmds.c | 2 +-
src/backend/executor/execExpr.c  | 2 +-
src/backend/executor/nodeIncrementalSort.c   | 2 +-
src/backend/executor/nodeLimit.c | 2 +-
src/backend/optimizer/path/allpaths.c| 2 +-
src/backend/optimizer/plan/analyzejoins.c| 2 +-
src/backend/partitioning/partbounds.c| 2 +-
src/backend/postmaster/interrupt.c   | 2 +-
src/backend/statistics/dependencies.c| 2 +-
src/backend/statistics/extended_stats.c  | 2 +-
src/backend/storage/buffer/bufmgr.c  | 2 +-
src/backend/utils/adt/varlena.c  | 2 +-
src/bin/pg_rewind/parsexlog.c| 2 +-
src/bin/pgbench/pgbench.c| 2 +-
src/interfaces/libpq/fe-connect.c| 2 +-
src/test/modules/dummy_index_am/dummy_index_am.c | 2 +-
25 files changed, 28 insertions(+), 28 deletions(-)



Re: pgsql: Allow run-time pruning on nested Append/MergeAppend nodes

2020-11-01 Thread Michael Paquier
Hi David,

On Mon, Nov 02, 2020 at 12:49:52AM +, David Rowley wrote:
> Allow run-time pruning on nested Append/MergeAppend nodes
> 
> Previously we only tagged on the required information to allow the
> executor to perform run-time partition pruning for Append/MergeAppend
> nodes belonging to base relations.  It was thought that nested
> Append/MergeAppend nodes were just about always pulled up into the
> top-level Append/MergeAppend and that making the run-time pruning info for
> any sub Append/MergeAppend nodes was a waste of time.  However, that was
> likely badly thought through.

fairywen is telling that some of the plans produced in these new tests
are not stable:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2020-11-02%2005%3A20%3A53

Thanks,
--
Michael


signature.asc
Description: PGP signature


Re: pgsql: Allow run-time pruning on nested Append/MergeAppend nodes

2020-11-01 Thread David Rowley
On Mon, 2 Nov 2020 at 19:30, Michael Paquier  wrote:
> fairywen is telling that some of the plans produced in these new tests
> are not stable:

Thanks. Looking at that now.

David




pgsql: Fix unstable partition_prune regression tests

2020-11-01 Thread David Rowley
Fix unstable partition_prune regression tests

This was broken recently by a929e17e5.  I'd failed to remember that
parallel tests should have their EXPLAIN output run through the
explain_parallel_append function so that the output is stable when
parallel workers fail to start.

fairywren was first to notice.

Reported-by: Michael Paquier
Discussion: https://postgr.es/m/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/90d8f1b1826ce076a502a43fe7c88423b46c6349

Modified Files
--
src/test/regress/expected/partition_prune.out | 45 +--
src/test/regress/sql/partition_prune.sql  |  9 +++---
2 files changed, 26 insertions(+), 28 deletions(-)