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

From David Rowley
Subject Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)
Date
Msg-id CAKJS1f-N4D5hSR+FFf=P8ZYSPsjodQx1t0YS9rraFCPgNH1MzA@mail.gmail.com
Whole thread Raw
In response to Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)  (Steve Singer <steve@ssinger.info>)
Responses Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)
Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)
List pgsql-hackers
Thanks for looking at this.

On 1 November 2018 at 16:07, Steve Singer <steve@ssinger.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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: POC: Cleaning up orphaned files using undo logs
Next
From: Amit Langote
Date:
Subject: Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT