On the publisher side, <varname>debug_logical_replication_streaming</varname>

allows streaming or serializing changes immediately in logical decoding.

When set to <literal>immediate</literal>, stream each change if the

<link linkend="sql-createsubscription-with-streaming"><literal>streaming</literal></link>

<link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>

option of

<link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>

is enabled, otherwise, serialize each change. When set to

will be filled with the default value as specified in the definition of the

target table. However, logical replication in binary format is more

restrictive. See the

<link linkend="sql-createsubscription-with-binary"><literal>binary</literal></link>

<link linkend="sql-createsubscription-params-with-binary"><literal>binary</literal></link>

option of <command>CREATE SUBSCRIPTION</command> for details.

</para>

<para>

Create publications for the tables. The publications <literal>pub2</literal>

and <literal>pub3a</literal> disallow some

<link linkend="sql-createpublication-with-publish"><literal>publish</literal></link>

<link linkend="sql-createpublication-params-with-publish"><literal>publish</literal></link>

operations. The publication <literal>pub3b</literal> has a row filter (see

<xref linkend="logical-replication-row-filter"/>).

<programlisting>

<para>

Example 2: Where the subscription says <literal>connect = false</literal>,

but also specifies the

<link linkend="sql-createsubscription-with-slot-name"><literal>slot_name</literal></link>

<link linkend="sql-createsubscription-params-with-slot-name"><literal>slot_name</literal></link>

option.

<itemizedlist>

<listitem>

then the row is not replicated. The <literal>WHERE</literal> clause expression

is evaluated with the same role used for the replication connection (i.e.

the role specified in the

<link linkend="sql-createsubscription-connection"><literal>CONNECTION</literal></link>

<link linkend="sql-createsubscription-params-connection"><literal>CONNECTION</literal></link>

clause of the <xref linkend="sql-createsubscription"/>). Row filters have

no effect for <command>TRUNCATE</command> command.

</para>

<para>

If the publication contains a partitioned table, the publication parameter

<link linkend="sql-createpublication-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

<link linkend="sql-createpublication-params-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

determines which row filter is used. If <literal>publish_via_partition_root</literal>

is <literal>true</literal>, the <emphasis>root partitioned table's</emphasis>

row filter is used. Otherwise, if <literal>publish_via_partition_root</literal>

<warning>

<para>

Because initial data synchronization does not take into account the

<link linkend="sql-createpublication-with-publish"><literal>publish</literal></link>

<link linkend="sql-createpublication-params-with-publish"><literal>publish</literal></link>

parameter when copying existing table data, some rows may be copied that

would not be replicated using DML. Refer to

<xref linkend="logical-replication-snapshot"/>, and see

<para>

If the subscription has several publications in which the same table has

been published with different row filters (for the same

<link linkend="sql-createpublication-with-publish"><literal>publish</literal></link>

<link linkend="sql-createpublication-params-with-publish"><literal>publish</literal></link>

operation), those expressions get ORed together, so that rows satisfying

<emphasis>any</emphasis> of the expressions will be replicated. This means all

the other row filters for the same table become redundant if:

<listitem>

<para>

One of the publications was created using

<link linkend="sql-createpublication-for-all-tables"><literal>FOR ALL TABLES</literal></link>.

<link linkend="sql-createpublication-params-for-all-tables"><literal>FOR ALL TABLES</literal></link>.

This clause does not allow row filters.

</para>

</listitem>

<listitem>

<para>

One of the publications was created using

<link linkend="sql-createpublication-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>

<link linkend="sql-createpublication-params-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>

and the table belongs to the referred schema. This clause does not allow

row filters.

</para>

<para>

The following examples show how the publication parameter

<link linkend="sql-createpublication-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

<link linkend="sql-createpublication-params-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

determines whether the row filter of the parent or child table will be used

in the case of partitioned tables.

</para>

<para>

Specifying a column list when the publication also publishes

<link linkend="sql-createpublication-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>

<link linkend="sql-createpublication-params-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>

is not supported.

</para>

<para>

For partitioned tables, the publication parameter

<link linkend="sql-createpublication-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

<link linkend="sql-createpublication-params-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

determines which column list is used. If <literal>publish_via_partition_root</literal>

is <literal>true</literal>, the root partitioned table's column list is

used. Otherwise, if <literal>publish_via_partition_root</literal> is

either by <link linkend="sql-altersubscription-params-disable">

<command>ALTER SUBSCRIPTION ... DISABLE</command></link> or, the

subscription can be used with the

<link linkend="sql-createsubscription-with-disable-on-error"><literal>disable_on_error</literal></link>

<link linkend="sql-createsubscription-params-with-disable-on-error"><literal>disable_on_error</literal></link>

option. Then, you can use <function>pg_replication_origin_advance()</function>

function with the <parameter>node_name</parameter> (i.e., <literal>pg_16395</literal>)

and the next LSN of the finish LSN (i.e., 0/14C0379). The current position of

<para>

When the

<link linkend="sql-createsubscription-with-streaming"><literal>streaming</literal></link>

<link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>

mode is <literal>parallel</literal>, the finish LSN of failed transactions

may not be logged. In that case, it may be necessary to change the streaming

mode to <literal>on</literal> or <literal>off</literal> and cause the same

using the identity and schema of the partitioned root table instead of

that of the individual leaf partitions in which the changes actually

originate (see

<link linkend="sql-createpublication-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

<link linkend="sql-createpublication-params-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>

parameter of <command>CREATE PUBLICATION</command>).

</para>

</listitem>

<note>

<para>

The publication

<link linkend="sql-createpublication-with-publish"><literal>publish</literal></link>

<link linkend="sql-createpublication-params-with-publish"><literal>publish</literal></link>

parameter only affects what DML operations will be replicated. The

initial data synchronization does not take this parameter into account

when copying the existing table data.

zero rows in this view. If the initial data synchronization of any

table is in progress, there will be additional workers for the tables

being synchronized. Moreover, if the

<link linkend="sql-createsubscription-with-streaming"><literal>streaming</literal></link>

<link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>

transaction is applied in parallel, there may be additional parallel apply

workers.

</para>

subscribing side in order to become effective. Note also that

<literal>DROP TABLES IN SCHEMA</literal> will not drop any schema tables

that were specified using

<link linkend="sql-createpublication-for-table"><literal>FOR TABLE</literal></link>/

<link linkend="sql-createpublication-params-for-table"><literal>FOR TABLE</literal></link>/

<literal>ADD TABLE</literal>, and the combination of <literal>DROP</literal>

with a <literal>WHERE</literal> clause is not allowed.

</para>

new owning role, and that role must have <literal>CREATE</literal>

privilege on the database.

Also, the new owner of a

<link linkend="sql-createpublication-for-all-tables"><literal>FOR ALL TABLES</literal></link>

or <link linkend="sql-createpublication-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>

<link linkend="sql-createpublication-params-for-all-tables"><literal>FOR ALL TABLES</literal></link>

or <link linkend="sql-createpublication-params-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>

publication must be a superuser. However, a superuser can

change the ownership of a publication regardless of these restrictions.

</para>

executed inside a transaction block.

These commands also cannot be executed when the subscription has

<link linkend="sql-createsubscription-with-two-phase"><literal>two_phase</literal></link>

<link linkend="sql-createsubscription-params-with-two-phase"><literal>two_phase</literal></link>

commit enabled, unless

<link linkend="sql-createsubscription-with-copy-data"><literal>copy_data</literal></link>

<link linkend="sql-createsubscription-params-with-copy-data"><literal>copy_data</literal></link>

is <literal>false</literal>. See column <structfield>subtwophasestate</structfield>

of <link linkend="catalog-pg-subscription"><structname>pg_subscription</structname></link>

to know the actual two-phase state.

<para>

See <xref linkend="sql-createsubscription-notes"/> for details of

how <literal>copy_data = true</literal> can interact with the

<link linkend="sql-createsubscription-with-origin"><literal>origin</literal></link>

<link linkend="sql-createsubscription-params-with-origin"><literal>origin</literal></link>

parameter.

</para>

<para>

See the

<link linkend="sql-createsubscription-with-binary"><literal>binary</literal></link>

<link linkend="sql-createsubscription-params-with-binary"><literal>binary</literal></link>

parameter of <command>CREATE SUBSCRIPTION</command> for details about

copying pre-existing data in binary format.

</para>

This clause alters parameters originally set by

<xref linkend="sql-createsubscription"/>. See there for more

information. The parameters that can be altered are

<link linkend="sql-createsubscription-with-slot-name"><literal>slot_name</literal></link>,

<link linkend="sql-createsubscription-with-synchronous-commit"><literal>synchronous_commit</literal></link>,

<link linkend="sql-createsubscription-with-binary"><literal>binary</literal></link>,

<link linkend="sql-createsubscription-with-streaming"><literal>streaming</literal></link>,

<link linkend="sql-createsubscription-with-disable-on-error"><literal>disable_on_error</literal></link>,

<link linkend="sql-createsubscription-with-password-required"><literal>password_required</literal></link>,

<link linkend="sql-createsubscription-with-run-as-owner"><literal>run_as_owner</literal></link>, and

<link linkend="sql-createsubscription-with-origin"><literal>origin</literal></link>.

<link linkend="sql-createsubscription-params-with-slot-name"><literal>slot_name</literal></link>,

<link linkend="sql-createsubscription-params-with-synchronous-commit"><literal>synchronous_commit</literal></link>,

<link linkend="sql-createsubscription-params-with-binary"><literal>binary</literal></link>,

<link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>,

<link linkend="sql-createsubscription-params-with-disable-on-error"><literal>disable_on_error</literal></link>,

<link linkend="sql-createsubscription-params-with-password-required"><literal>password_required</literal></link>,

<link linkend="sql-createsubscription-params-with-run-as-owner"><literal>run_as_owner</literal></link>, and

<link linkend="sql-createsubscription-params-with-origin"><literal>origin</literal></link>.

Only a superuser can set <literal>password_required = false</literal>.

</para>

</listitem>

the logical replication worker skips all data modification changes within

the transaction. This option has no effect on the transactions that are

already prepared by enabling

<link linkend="sql-createsubscription-with-two-phase"><literal>two_phase</literal></link>

<link linkend="sql-createsubscription-params-with-two-phase"><literal>two_phase</literal></link>

on the subscriber.

After the logical replication worker successfully skips the transaction or

finishes a transaction, the LSN (stored in

<title>Parameters</title>

<variablelist>

<varlistentry id="sql-createpublication-name">

<varlistentry id="sql-createpublication-params-name">

<term><replaceable class="parameter">name</replaceable></term>

<listitem>

<para>

</listitem>

</varlistentry>

<varlistentry id="sql-createpublication-for-table">

<varlistentry id="sql-createpublication-params-for-table">

<term><literal>FOR TABLE</literal></term>

<listitem>

<para>

</listitem>

</varlistentry>

<varlistentry id="sql-createpublication-for-all-tables">

<varlistentry id="sql-createpublication-params-for-all-tables">

<term><literal>FOR ALL TABLES</literal></term>

<listitem>

<para>

</listitem>

</varlistentry>

<varlistentry id="sql-createpublication-for-tables-in-schema">

<varlistentry id="sql-createpublication-params-for-tables-in-schema">

<term><literal>FOR TABLES IN SCHEMA</literal></term>

<listitem>

<para>

</listitem>

</varlistentry>

<varlistentry id="sql-createpublication-with">

<varlistentry id="sql-createpublication-params-with">

<term><literal>WITH ( <replaceable class="parameter">publication_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )</literal></term>

<listitem>

<para>

This clause specifies optional parameters for a publication. The

following parameters are supported:

<variablelist>

<varlistentry id="sql-createpublication-with-publish">

<varlistentry id="sql-createpublication-params-with-publish">

<term><literal>publish</literal> (<type>string</type>)</term>

<listitem>

<para>

</listitem>

</varlistentry>

<varlistentry id="sql-createpublication-with-publish-via-partition-root">

<varlistentry id="sql-createpublication-params-with-publish-via-partition-root">

<term><literal>publish_via_partition_root</literal> (<type>boolean</type>)</term>

<listitem>

<para>