Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal) - Mailing list pgsql-hackers

The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            tested, failed

--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1534,9 +1534,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
     <command>TRUNCATE</command> command. In such cases no WAL
     needs to be written, because in case of an error, the files
     containing the newly loaded data will be removed anyway.
-    However, this consideration only applies when
-    <xref linkend="guc-wal-level"/> is <literal>minimal</literal> as all commands
-    must write WAL otherwise.
+    However, this consideration only applies for non-partitioned
+    tables when <xref linkend="guc-wal-level"/> is
+    <literal>minimal</literal> as all commands must write WAL
+    otherwise.
    </para>

Would this be better as "However, this consideration only applies for non-partitioned and the wal_level is minimal"
(Switching the 'when' to 'and the')



--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -222,9 +222,10 @@ COPY { <replaceable class="parameter">table_name</replaceable> [ ( <replaceable
       Requests copying the data with rows already frozen, just as they
       would be after running the <command>VACUUM FREEZE</command> command.
       This is intended as a performance option for initial data loading.
-      Rows will be frozen only if the table being loaded has been created
-      or truncated in the current subtransaction, there are no cursors
-      open and there are no older snapshots held by this transaction.
+      Rows will be frozen only for non-partitioned tables if the table
+      being loaded has been created or truncated in the current
+      subtransaction, there are no cursors open and there are no older
+      snapshots held by this transaction.

Similar concern with above

When I read this comment it makes me think that the table is partitioned then the rows will be frozen even if the table
wascreated by an earlier transaction. 
 
Do we want to instead say "Rows will be frozen if the table is not partitioned and the table being loaded has
been...."

Other than that the patch looks fine and works as expected.

The new status of this patch is: Waiting on Author