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 was created 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