On the publisher side, debug_logical_replication_streaming
allows streaming or serializing changes immediately in logical decoding.
When set to immediate, stream each change if the
- streaming
+ params-with-streaming">streaming
option of
CREATE SUBSCRIPTION
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
- binary
+ params-with-binary">binary
option of CREATE SUBSCRIPTION for details.
Create publications for the tables. The publications pub2
and pub3a disallow some
- publish
+ params-with-publish">publish
operations. The publication pub3b has a row filter (see
).
Example 2: Where the subscription says connect = false,
but also specifies the
- slot_name
+ params-with-slot-name">slot_name
option.
then the row is not replicated. The WHERE clause expression
is evaluated with the same role used for the replication connection (i.e.
the role specified in the
- CONNECTION
+ params-connection">CONNECTION
clause of the ). Row filters have
no effect for TRUNCATE command.
If the publication contains a partitioned table, the publication parameter
- publish_via_partition_root
+ params-with-publish-via-partition-root">publish_via_partition_root
determines which row filter is used. If publish_via_partition_root
is true, the root partitioned table's
row filter is used. Otherwise, if publish_via_partition_root
Because initial data synchronization does not take into account the
- publish
+ params-with-publish">publish
parameter when copying existing table data, some rows may be copied that
would not be replicated using DML. Refer to
, and see
If the subscription has several publications in which the same table has
been published with different row filters (for the same
- publish
+ params-with-publish">publish
operation), those expressions get ORed together, so that rows satisfying
any of the expressions will be replicated. This means all
the other row filters for the same table become redundant if:
One of the publications was created using
- FOR ALL TABLES.
+ params-for-all-tables">FOR ALL TABLES.
This clause does not allow row filters.
One of the publications was created using
- FOR TABLES IN SCHEMA
+ params-for-tables-in-schema">FOR TABLES IN SCHEMA
and the table belongs to the referred schema. This clause does not allow
row filters.
The following examples show how the publication parameter
- publish_via_partition_root
+ params-with-publish-via-partition-root">publish_via_partition_root
determines whether the row filter of the parent or child table will be used
in the case of partitioned tables.
Specifying a column list when the publication also publishes
- FOR TABLES IN SCHEMA
+ params-for-tables-in-schema">FOR TABLES IN SCHEMA
is not supported.
For partitioned tables, the publication parameter
- publish_via_partition_root
+ params-with-publish-via-partition-root">publish_via_partition_root
determines which column list is used. If publish_via_partition_root
is true, the root partitioned table's column list is
used. Otherwise, if publish_via_partition_root is
either by
ALTER SUBSCRIPTION ... DISABLE or, the
subscription can be used with the
- disable_on_error
+ params-with-disable-on-error">disable_on_error
option. Then, you can use pg_replication_origin_advance()
function with the
node_name (i.e.,
pg_16395)
and the next LSN of the finish LSN (i.e., 0/14C0379). The current position of
When the
- streaming
+ params-with-streaming">streaming
mode is parallel, the finish LSN of failed transactions
may not be logged. In that case, it may be necessary to change the streaming
mode to on or off 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
- publish_via_partition_root
+ params-with-publish-via-partition-root">publish_via_partition_root
parameter of CREATE PUBLICATION).
The publication
- publish
+ params-with-publish">publish
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
- streaming
+ params-with-streaming">streaming
transaction is applied in parallel, there may be additional parallel apply
workers.
subscribing side in order to become effective. Note also that
DROP TABLES IN SCHEMA will not drop any schema tables
that were specified using
- FOR TABLE/
+ params-for-table">FOR TABLE/
ADD TABLE, and the combination of DROP
with a WHERE clause is not allowed.
new owning role, and that role must have CREATE
privilege on the database.
Also, the new owner of a
- FOR ALL TABLES
- or FOR TABLES IN SCHEMA
+ params-for-all-tables">FOR ALL TABLES
+ or params-for-tables-in-schema">FOR TABLES IN SCHEMA
publication must be a superuser. However, a superuser can
change the ownership of a publication regardless of these restrictions.
executed inside a transaction block.
These commands also cannot be executed when the subscription has
- two_phase
+ params-with-two-phase">two_phase
commit enabled, unless
- copy_data
+ params-with-copy-data">copy_data
is false. See column subtwophasestate
of pg_subscription
to know the actual two-phase state.
See for details of
how copy_data = true can interact with the
- origin
+ params-with-origin">origin
parameter.
See the
- binary
+ params-with-binary">binary
parameter of CREATE SUBSCRIPTION for details about
copying pre-existing data in binary format.
This clause alters parameters originally set by
. See there for more
information. The parameters that can be altered are
- slot_name,
- synchronous_commit,
- binary,
- streaming,
- disable_on_error,
- password_required,
- run_as_owner, and
- origin.
+ params-with-slot-name">slot_name,
+ params-with-synchronous-commit">synchronous_commit,
+ params-with-binary">binary,
+ params-with-streaming">streaming,
+ params-with-disable-on-error">disable_on_error,
+ params-with-password-required">password_required,
+ params-with-run-as-owner">run_as_owner, and
+ params-with-origin">origin.
Only a superuser can set password_required = false.
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
- two_phase
+ params-with-two-phase">two_phase
on the subscriber.
After the logical replication worker successfully skips the transaction or
finishes a transaction, the LSN (stored in
Parameters
-
+ params-name">
name
-
+ params-for-table">
FOR TABLE
-
+ params-for-all-tables">
FOR ALL TABLES
-
+ params-for-tables-in-schema">
FOR TABLES IN SCHEMA
-
+ params-with">
WITH ( publication_parameter [= value] [, ... ] )
following parameters are supported:
-
+ params-with-publish">
publish (string)
-
+ params-with-publish-via-partition-root">
publish_via_partition_root (boolean)
Parameters
-
+ params-name">
subscription_name
-
+ params-connection">
CONNECTION 'conninfo'
-
+ arams-publication">
PUBLICATION publication_name [, ...]
-
+ params-with">
WITH ( subscription_parameter [= value] [, ... ] )
-
+ params-with-connect">
connect (boolean)
-
+ params-with-create-slot">
create_slot (boolean)
-
+ params-with-enabled">
enabled (boolean)
-
+ params-with-slot-name">
slot_name (string)
-
+ params-with-binary">
binary (boolean)
-
+ params-with-copy-data">
copy_data (boolean)
-
+ params-with-streaming">
streaming (enum)
-
+ params-with-synchronous-commit">
synchronous_commit (enum)
-
+ params-with-two-phase">
two_phase (boolean)
-
+ params-with-disable-on-error">
disable_on_error (boolean)
-
+ params-with-password-required">
password_required (boolean)
-
+ params-with-run-as-owner">
run_as_owner (boolean)
-
+ params-with-origin">
origin (string)
the case of different WHERE clauses, if one of the
publications has no WHERE clause (referring to that
publish operation) or the publication is declared as
- FOR ALL TABLES
- or FOR TABLES IN SCHEMA,
+ params-for-all-tables">FOR ALL TABLES
+ or params-for-tables-in-schema">FOR TABLES IN SCHEMA,
rows are always published regardless of the definition of the other
expressions. If the subscriber is a
PostgreSQL version before 15, then any row filtering is ignored during the initial data
deleting any initially copied data that would be incompatible with
subsequent filtering. Because initial data synchronization does not take
into account the publication
- publish
+ params-with-publish">publish
parameter when copying existing table data, some rows may be copied that
would not be replicated using DML. See
for examples.
truncate the target tables before initiating a new full table copy. If users
intend to copy initial data during refresh they must create the slot with
two_phase = false. After the initial sync, the
- two_phase
+ params-with-two-phase">two_phase
option will be automatically enabled by the subscriber if the subscription
had been originally created with two_phase = true option.
tables they contain. Unlike the underlying catalog
pg_publication_rel,
this view expands publications defined as
- FOR ALL TABLES
- and FOR TABLES IN SCHEMA,
+ params-for-all-tables">FOR ALL TABLES
+ and params-for-tables-in-schema">FOR TABLES IN SCHEMA,
so for such publications there will be a row for each eligible table.
projects / postgresql.git / commitdiff