2017-01-19 12:00:00 -05:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* pgoutput.h
|
|
|
|
|
* Logical Replication output plugin
|
|
|
|
|
*
|
2022-01-07 19:04:57 -05:00
|
|
|
* Copyright (c) 2015-2022, PostgreSQL Global Development Group
|
2017-01-19 12:00:00 -05:00
|
|
|
*
|
|
|
|
|
* IDENTIFICATION
|
2022-01-24 19:40:04 -05:00
|
|
|
* src/include/replication/pgoutput.h
|
2017-01-19 12:00:00 -05:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef PGOUTPUT_H
|
|
|
|
|
#define PGOUTPUT_H
|
|
|
|
|
|
2017-01-21 15:49:53 -05:00
|
|
|
#include "nodes/pg_list.h"
|
2017-01-19 12:00:00 -05:00
|
|
|
|
|
|
|
|
typedef struct PGOutputData
|
|
|
|
|
{
|
|
|
|
|
MemoryContext context; /* private memory context for transient
|
|
|
|
|
* allocations */
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-21 21:24:12 -05:00
|
|
|
MemoryContext cachectx; /* private memory context for cache data */
|
2017-01-19 12:00:00 -05:00
|
|
|
|
2020-07-18 12:44:51 -04:00
|
|
|
/* client-supplied info: */
|
2017-01-19 12:00:00 -05:00
|
|
|
uint32 protocol_version;
|
|
|
|
|
List *publication_names;
|
|
|
|
|
List *publications;
|
2020-07-18 12:44:51 -04:00
|
|
|
bool binary;
|
2021-04-05 22:56:31 -04:00
|
|
|
bool streaming;
|
2021-04-05 23:10:47 -04:00
|
|
|
bool messages;
|
Add support for prepared transactions to built-in logical replication.
To add support for streaming transactions at prepare time into the
built-in logical replication, we need to do the following things:
* Modify the output plugin (pgoutput) to implement the new two-phase API
callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle two-phase
transactions by replaying them on prepare.
* Add a new SUBSCRIPTION option "two_phase" to allow users to enable
two-phase transactions. We enable the two_phase once the initial data sync
is over.
We however must explicitly disable replication of two-phase transactions
during replication slot creation, even if the plugin supports it. We
don't need to replicate the changes accumulated during this phase,
and moreover, we don't have a replication connection open so we don't know
where to send the data anyway.
The streaming option is not allowed with this new two_phase option. This
can be done as a separate patch.
We don't allow to toggle two_phase option of a subscription because it can
lead to an inconsistent replica. For the same reason, we don't allow to
refresh the publication once the two_phase is enabled for a subscription
unless copy_data option is false.
Author: Peter Smith, Ajin Cherian and Amit Kapila based on previous work by Nikhil Sontakke and Stas Kelvich
Reviewed-by: Amit Kapila, Sawada Masahiko, Vignesh C, Dilip Kumar, Takamichi Osumi, Greg Nancarrow
Tested-By: Haiying Tang
Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru
Discussion: https://postgr.es/m/CAA4eK1+opiV4aFTmWWUF9h_32=HfPOW9vZASHarT0UA5oBrtGw@mail.gmail.com
2021-07-13 22:03:50 -04:00
|
|
|
bool two_phase;
|
2022-07-20 23:17:38 -04:00
|
|
|
char *origin;
|
2017-01-19 12:00:00 -05:00
|
|
|
} PGOutputData;
|
|
|
|
|
|
|
|
|
|
#endif /* PGOUTPUT_H */
|
