From 73a60051379b35a0bec399edfe369c59e50cc775 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 23 Sep 2018 18:34:18 -0400 Subject: [PATCH] Doc: warn against using parallel restore with --load-via-partition-root. This isn't terribly safe, and making it so doesn't seem like a small project, so for the moment just warn against it. Discussion: https://postgr.es/m/13624.1535486019@sss.pgh.pa.us --- doc/src/sgml/ref/pg_dump.sgml | 29 +++++++++++++++++++++-------- doc/src/sgml/ref/pg_dumpall.sgml | 23 +++++++++++++++-------- 2 files changed, 36 insertions(+), 16 deletions(-) diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index 8286b2dddd..790e81c32c 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/sgml/ref/pg_dump.sgml @@ -793,13 +793,26 @@ PostgreSQL documentation - When dumping a COPY or INSERT statement for a partitioned table, - target the root of the partitioning hierarchy which contains it rather - than the partition itself. This may be useful when reloading data on - a server where rows do not always fall into the same partitions as - they did on the original server. This could happen, for example, if - the partitioning column is of type text and the two system have - different definitions of the collation used to partition the data. + When dumping data for a table partition, make + the COPY or INSERT statements + target the root of the partitioning hierarchy that contains it, rather + than the partition itself. This causes the appropriate partition to + be re-determined for each row when the data is loaded. This may be + useful when reloading data on a server where rows do not always fall + into the same partitions as they did on the original server. That + could happen, for example, if the partitioning column is of type text + and the two systems have different definitions of the collation used + to sort the partitioning column. + + + + It is best not to use parallelism when restoring from an archive made + with this option, because pg_restore will + not know exactly which partition(s) a given archive data item will + load data into. This could result in inefficiency due to lock + conflicts between parallel jobs, or perhaps even reload failures due + to foreign key constraints being set up before all the relevant data + is loaded. @@ -915,7 +928,7 @@ PostgreSQL documentation Add ON CONFLICT DO NOTHING to INSERT commands. - This option is not valid unless or + This option is not valid unless or is also specified. diff --git a/doc/src/sgml/ref/pg_dumpall.sgml b/doc/src/sgml/ref/pg_dumpall.sgml index 94d76c30db..c51a130f43 100644 --- a/doc/src/sgml/ref/pg_dumpall.sgml +++ b/doc/src/sgml/ref/pg_dumpall.sgml @@ -330,14 +330,21 @@ PostgreSQL documentation - When dumping a COPY or INSERT statement for a partitioned table, - target the root of the partitioning hierarchy which contains it rather - than the partition itself. This may be useful when reloading data on - a server where rows do not always fall into the same partitions as - they did on the original server. This could happen, for example, if - the partitioning column is of type text and the two system have - different definitions of the collation used to partition the data. + When dumping data for a table partition, make + the COPY or INSERT statements + target the root of the partitioning hierarchy that contains it, rather + than the partition itself. This causes the appropriate partition to + be re-determined for each row when the data is loaded. This may be + useful when reloading data on a server where rows do not always fall + into the same partitions as they did on the original server. That + could happen, for example, if the partitioning column is of type text + and the two systems have different definitions of the collation used + to sort the partitioning column. + + @@ -452,7 +459,7 @@ PostgreSQL documentation Add ON CONFLICT DO NOTHING to INSERT commands. - This option is not valid unless or + This option is not valid unless or is also specified.