2017-01-19 18:00:00 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* logicalproto.h
|
|
|
|
* logical replication protocol
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Copyright (c) 2015-2020, PostgreSQL Global Development Group
|
2017-01-19 18:00:00 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/include/replication/logicalproto.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef LOGICAL_PROTO_H
|
|
|
|
#define LOGICAL_PROTO_H
|
|
|
|
|
|
|
|
#include "replication/reorderbuffer.h"
|
|
|
|
#include "utils/rel.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Protocol capabilities
|
|
|
|
*
|
2020-09-26 06:38:00 +02:00
|
|
|
* LOGICALREP_PROTO_VERSION_NUM is our native protocol.
|
|
|
|
* LOGICALREP_PROTO_MAX_VERSION_NUM is the greatest version we can support.
|
|
|
|
* LOGICALREP_PROTO_MIN_VERSION_NUM is the oldest version we
|
2017-01-19 18:00:00 +01:00
|
|
|
* have backwards compatibility for. The client requests protocol version at
|
|
|
|
* connect time.
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
*
|
|
|
|
* LOGICALREP_PROTO_STREAM_VERSION_NUM is the minimum protocol version with
|
|
|
|
* support for streaming large transactions.
|
2017-01-19 18:00:00 +01:00
|
|
|
*/
|
|
|
|
#define LOGICALREP_PROTO_MIN_VERSION_NUM 1
|
2020-09-26 06:38:00 +02:00
|
|
|
#define LOGICALREP_PROTO_VERSION_NUM 1
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
#define LOGICALREP_PROTO_STREAM_VERSION_NUM 2
|
2020-09-26 06:38:00 +02:00
|
|
|
#define LOGICALREP_PROTO_MAX_VERSION_NUM LOGICALREP_PROTO_STREAM_VERSION_NUM
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2020-07-20 19:40:16 +02:00
|
|
|
/*
|
|
|
|
* This struct stores a tuple received via logical replication.
|
|
|
|
* Keep in mind that the columns correspond to the *remote* table.
|
|
|
|
*/
|
2017-01-19 18:00:00 +01:00
|
|
|
typedef struct LogicalRepTupleData
|
|
|
|
{
|
2020-07-18 18:44:51 +02:00
|
|
|
/* Array of StringInfos, one per column; some may be unused */
|
|
|
|
StringInfoData *colvalues;
|
|
|
|
/* Array of markers for null/unchanged/text/binary, one per column */
|
|
|
|
char *colstatus;
|
2020-07-20 19:40:16 +02:00
|
|
|
/* Length of above arrays */
|
|
|
|
int ncols;
|
2017-01-19 18:00:00 +01:00
|
|
|
} LogicalRepTupleData;
|
|
|
|
|
2020-07-18 18:44:51 +02:00
|
|
|
/* Possible values for LogicalRepTupleData.colstatus[colnum] */
|
|
|
|
/* These values are also used in the on-the-wire protocol */
|
|
|
|
#define LOGICALREP_COLUMN_NULL 'n'
|
|
|
|
#define LOGICALREP_COLUMN_UNCHANGED 'u'
|
|
|
|
#define LOGICALREP_COLUMN_TEXT 't'
|
|
|
|
#define LOGICALREP_COLUMN_BINARY 'b' /* added in PG14 */
|
|
|
|
|
2017-05-17 22:31:56 +02:00
|
|
|
typedef uint32 LogicalRepRelId;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Relation information */
|
|
|
|
typedef struct LogicalRepRelation
|
|
|
|
{
|
|
|
|
/* Info coming from the remote side. */
|
2017-05-17 22:31:56 +02:00
|
|
|
LogicalRepRelId remoteid; /* unique id of the relation */
|
|
|
|
char *nspname; /* schema name */
|
|
|
|
char *relname; /* relation name */
|
|
|
|
int natts; /* number of columns */
|
|
|
|
char **attnames; /* column names */
|
|
|
|
Oid *atttyps; /* column types */
|
|
|
|
char replident; /* replica identity */
|
2020-03-19 08:17:50 +01:00
|
|
|
char relkind; /* remote relation kind */
|
2017-05-17 22:31:56 +02:00
|
|
|
Bitmapset *attkeys; /* Bitmap of key columns */
|
2017-01-19 18:00:00 +01:00
|
|
|
} LogicalRepRelation;
|
|
|
|
|
|
|
|
/* Type mapping info */
|
|
|
|
typedef struct LogicalRepTyp
|
|
|
|
{
|
logical replication: fix OID type mapping mechanism
The logical replication type map seems to have been misused by its only
caller -- it would try to use the remote OID as input for local type
routines, which unsurprisingly could result in bogus "cache lookup
failed for type XYZ" errors, or random other type names being picked up
if they happened to use the right OID. Fix that, changing
Oid logicalrep_typmap_getid(Oid remoteid) to
char *logicalrep_typmap_gettypname(Oid remoteid)
which is more useful. If the remote type is not part of the typmap,
this simply prints "unrecognized type" instead of choking trying to
figure out -- a pointless exercise (because the only input for that
comes from replication messages, which are not under the local node's
control) and dangerous to boot, when called from within an error context
callback.
Once that is done, it comes to light that the local OID in the typmap
entry was not being used for anything; the type/schema names are what we
need, so remove local type OID from that struct.
Once you do that, it becomes pointless to attach a callback to regular
syscache invalidation. So remove that also.
Reported-by: Dang Minh Huong
Author: Masahiko Sawada
Reviewed-by: Álvaro Herrera, Petr Jelínek, Dang Minh Huong, Atsushi Torikoshi
Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A6BE964@BPXM05GP.gisp.nec.co.jp
Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A6C4B0A@BPXM05GP.gisp.nec.co.jp
2018-03-15 01:34:26 +01:00
|
|
|
Oid remoteid; /* unique id of the remote type */
|
|
|
|
char *nspname; /* schema name of remote type */
|
|
|
|
char *typname; /* name of the remote type */
|
2017-01-19 18:00:00 +01:00
|
|
|
} LogicalRepTyp;
|
|
|
|
|
|
|
|
/* Transaction info */
|
|
|
|
typedef struct LogicalRepBeginData
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
XLogRecPtr final_lsn;
|
|
|
|
TimestampTz committime;
|
|
|
|
TransactionId xid;
|
2017-01-19 18:00:00 +01:00
|
|
|
} LogicalRepBeginData;
|
|
|
|
|
|
|
|
typedef struct LogicalRepCommitData
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
XLogRecPtr commit_lsn;
|
|
|
|
XLogRecPtr end_lsn;
|
|
|
|
TimestampTz committime;
|
2017-01-19 18:00:00 +01:00
|
|
|
} LogicalRepCommitData;
|
|
|
|
|
2017-05-17 22:31:56 +02:00
|
|
|
extern void logicalrep_write_begin(StringInfo out, ReorderBufferTXN *txn);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void logicalrep_read_begin(StringInfo in,
|
2019-05-22 19:04:48 +02:00
|
|
|
LogicalRepBeginData *begin_data);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void logicalrep_write_commit(StringInfo out, ReorderBufferTXN *txn,
|
2019-05-22 19:04:48 +02:00
|
|
|
XLogRecPtr commit_lsn);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void logicalrep_read_commit(StringInfo in,
|
2019-05-22 19:04:48 +02:00
|
|
|
LogicalRepCommitData *commit_data);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void logicalrep_write_origin(StringInfo out, const char *origin,
|
2019-05-22 19:04:48 +02:00
|
|
|
XLogRecPtr origin_lsn);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern char *logicalrep_read_origin(StringInfo in, XLogRecPtr *origin_lsn);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_insert(StringInfo out, TransactionId xid,
|
|
|
|
Relation rel, HeapTuple newtuple,
|
|
|
|
bool binary);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern LogicalRepRelId logicalrep_read_insert(StringInfo in, LogicalRepTupleData *newtup);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_update(StringInfo out, TransactionId xid,
|
|
|
|
Relation rel, HeapTuple oldtuple,
|
2020-07-18 18:44:51 +02:00
|
|
|
HeapTuple newtuple, bool binary);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern LogicalRepRelId logicalrep_read_update(StringInfo in,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool *has_oldtuple, LogicalRepTupleData *oldtup,
|
|
|
|
LogicalRepTupleData *newtup);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_delete(StringInfo out, TransactionId xid,
|
|
|
|
Relation rel, HeapTuple oldtuple,
|
|
|
|
bool binary);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern LogicalRepRelId logicalrep_read_delete(StringInfo in,
|
2019-05-22 19:04:48 +02:00
|
|
|
LogicalRepTupleData *oldtup);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_truncate(StringInfo out, TransactionId xid,
|
|
|
|
int nrelids, Oid relids[],
|
2019-05-22 19:04:48 +02:00
|
|
|
bool cascade, bool restart_seqs);
|
2018-04-07 17:24:53 +02:00
|
|
|
extern List *logicalrep_read_truncate(StringInfo in,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool *cascade, bool *restart_seqs);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_rel(StringInfo out, TransactionId xid,
|
|
|
|
Relation rel);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern LogicalRepRelation *logicalrep_read_rel(StringInfo in);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_typ(StringInfo out, TransactionId xid,
|
|
|
|
Oid typoid);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void logicalrep_read_typ(StringInfo out, LogicalRepTyp *ltyp);
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication 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 have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
extern void logicalrep_write_stream_start(StringInfo out, TransactionId xid,
|
|
|
|
bool first_segment);
|
|
|
|
extern TransactionId logicalrep_read_stream_start(StringInfo in,
|
|
|
|
bool *first_segment);
|
|
|
|
extern void logicalrep_write_stream_stop(StringInfo out);
|
|
|
|
extern void logicalrep_write_stream_commit(StringInfo out, ReorderBufferTXN *txn,
|
|
|
|
XLogRecPtr commit_lsn);
|
|
|
|
extern TransactionId logicalrep_read_stream_commit(StringInfo out,
|
|
|
|
LogicalRepCommitData *commit_data);
|
|
|
|
extern void logicalrep_write_stream_abort(StringInfo out, TransactionId xid,
|
|
|
|
TransactionId subxid);
|
|
|
|
extern void logicalrep_read_stream_abort(StringInfo in, TransactionId *xid,
|
|
|
|
TransactionId *subxid);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2019-07-29 05:28:30 +02:00
|
|
|
#endif /* LOGICAL_PROTO_H */
|