Home • Explore • Blog • CI
☰



postgresql
4th chunk of `doc/src/sgml/ref/create_subscription.sgml`
0fda6079966fe995652c632a677dec7d72923296d6574fee0000000100000fa2
   <type>integer</type> column, even though that would work fine in text
          format. Even when this option is enabled, only data types having binary
          send and receive functions will be transferred in binary. Note that
          the initial synchronization requires all data types to have binary
          send and receive functions, otherwise the synchronization will fail
          (see <xref linkend="sql-createtype"/> for more about send/receive
          functions).
         </para>

         <para>
          When doing cross-version replication, it could be that the
          publisher has a binary send function for some data type, but the
          subscriber lacks a binary receive function for that type.  In
          such a case, data transfer will fail, and
          the <literal>binary</literal> option cannot be used.
         </para>

         <para>
          If the publisher is a <productname>PostgreSQL</productname> version
          before 16, then any initial table synchronization will use text format
          even if <literal>binary = true</literal>.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-copy-data">
        <term><literal>copy_data</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          Specifies whether to copy pre-existing data in the publications
          that are being subscribed to when the replication starts.
          The default is <literal>true</literal>.
         </para>
         <para>
          If the publications contain <literal>WHERE</literal> clauses, it
          will affect what data is copied. Refer to the
          <xref linkend="sql-createsubscription-notes" /> for details.
         </para>
         <para>
          See <xref linkend="sql-createsubscription-notes"/> for details of how
          <literal>copy_data = true</literal> can interact with the
          <literal>origin</literal> parameter.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-streaming">
        <term><literal>streaming</literal> (<type>enum</type>)</term>
        <listitem>
         <para>
          Specifies whether to enable streaming of in-progress transactions
          for this subscription.  The default value is <literal>parallel</literal>,
          meaning incoming changes are directly applied via one of the parallel
          apply workers, if available. If no parallel apply worker is free to
          handle streaming transactions then the changes are written to
          temporary files and applied after the transaction is committed. Note
          that if an error happens in a parallel apply worker, the finish LSN
          of the remote transaction might not be reported in the server log.
         </para>

         <caution>
          <para>
           There is a risk of deadlock when the schemas of the publisher and
           subscriber differ, although such cases are rare. The apply worker
           is equipped to retry these transactions automatically.
          </para>
         </caution>

         <para>
          If set to <literal>on</literal>, the incoming changes are written to
          temporary files and then applied only after the transaction is
          committed on the publisher and received by the subscriber.
         </para>

         <para>
          If set to <literal>off</literal>, all transactions are fully decoded
          on the publisher and only then sent to the subscriber as a whole.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-synchronous-commit">
        <term><literal>synchronous_commit</literal> (<type>enum</type>)</term>
        <listitem>
         <para>
          The value of this parameter overrides the
          <xref linkend="guc-synchronous-commit"/> setting within this
          subscription's apply
Title: CREATE SUBSCRIPTION WITH Clause Parameters (Continued): binary, copy_data, streaming
Summary
This section details additional `WITH` clause parameters for `CREATE SUBSCRIPTION`. It expands on the `binary` parameter's limitations with PostgreSQL versions prior to 16. It then describes the `copy_data` parameter, which determines whether pre-existing data is copied upon replication start and the impact of `WHERE` clauses on this process. Finally, it covers the `streaming` parameter, which controls how in-progress transactions are handled (parallel apply, writing to temp files, or full decoding).