Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)

Thanks for looking at this.

On 1 November 2018 at 16:07, Steve Singer <steve(at)ssinger(dot)info> wrote:
> --- 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')

I ended up going with:

However, this consideration only applies when
<xref linkend="guc-wal-level"/> is <literal>minimal</literal> for
non-partitioned tables as all commands must write WAL otherwise.

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

I've changed this to:

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. It is
currently not possible to perform a <command>COPY FREEZE</command> on
a partitioned table.

Which is just the original text with the new sentence tagged onto the end.

> Other than that the patch looks fine and works as expected.
>
> The new status of this patch is: Waiting on Author

Thanks for looking at this. I've attached an updated patch.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services