mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Doc: warn against using parallel restore with --load-via-partition-root.

Browse Source 
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
This commit is contained in:
Tom Lane 2018-09-23 18:34:18 -04:00
parent 89b280e139
commit 73a6005137
2 changed files with 36 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
doc/src/sgml/ref/pg_dump.sgml
View File

@ -793,13 +793,26 @@ PostgreSQL documentation
<term><option>--load-via-partition-root</option></term>
<listitem>
<para>
When dumping a <command>COPY</command> or <command>INSERT</command> 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 <command>COPY</command> or <command>INSERT</command> 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.
</para>
<para>
It is best not to use parallelism when restoring from an archive made
with this option, because <application>pg_restore</application> 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.
</para>
</listitem>
</varlistentry>

21
doc/src/sgml/ref/pg_dumpall.sgml
View File

@ -330,14 +330,21 @@ PostgreSQL documentation
<term><option>--load-via-partition-root</option></term>
<listitem>
<para>
When dumping a <command>COPY</command> or <command>INSERT</command> 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 <command>COPY</command> or <command>INSERT</command> 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.
</para>
<!-- Currently, we don't need pg_dump's warning about parallelism here,
since parallel restore from a pg_dumpall script is impossible.
-->
</listitem>
</varlistentry>