2011-01-14 16:30:33 +01:00
|
|
|
%{
|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* repl_gram.y - Parser for the replication commands
|
|
|
|
*
|
2021-01-02 19:06:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
|
2011-01-14 16:30:33 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/replication/repl_gram.y
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2011-08-27 17:05:33 +02:00
|
|
|
#include "access/xlogdefs.h"
|
2011-01-23 23:39:18 +01:00
|
|
|
#include "nodes/makefuncs.h"
|
2011-08-06 20:53:49 +02:00
|
|
|
#include "nodes/replnodes.h"
|
2011-01-14 16:30:33 +01:00
|
|
|
#include "replication/walsender.h"
|
2011-09-12 20:24:29 +02:00
|
|
|
#include "replication/walsender_private.h"
|
2011-01-14 16:30:33 +01:00
|
|
|
|
2011-08-06 20:53:49 +02:00
|
|
|
|
2011-01-14 16:30:33 +01:00
|
|
|
/* Result of the parsing is returned here */
|
|
|
|
Node *replication_parse_result;
|
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
static SQLCmd *make_sqlcmd(void);
|
|
|
|
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Bison doesn't allocate anything that needs to live across parser calls,
|
|
|
|
* so we can easily have it use palloc instead of malloc. This prevents
|
|
|
|
* memory leaks if we error out during parsing. Note this only works with
|
|
|
|
* bison >= 2.0. However, in bison 1.875 the default is to use alloca()
|
|
|
|
* if possible, so there's not really much problem anyhow, at least if
|
|
|
|
* you're building with gcc.
|
|
|
|
*/
|
|
|
|
#define YYMALLOC palloc
|
|
|
|
#define YYFREE pfree
|
|
|
|
|
|
|
|
%}
|
|
|
|
|
|
|
|
%expect 0
|
2014-05-29 01:21:01 +02:00
|
|
|
%name-prefix="replication_yy"
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
%union {
|
|
|
|
char *str;
|
|
|
|
bool boolval;
|
2013-08-15 05:18:49 +02:00
|
|
|
uint32 uintval;
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
XLogRecPtr recptr;
|
|
|
|
Node *node;
|
2011-01-23 23:39:18 +01:00
|
|
|
List *list;
|
|
|
|
DefElem *defelt;
|
2011-01-14 16:30:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Non-keyword tokens */
|
2014-02-01 04:45:17 +01:00
|
|
|
%token <str> SCONST IDENT
|
2013-08-15 05:18:49 +02:00
|
|
|
%token <uintval> UCONST
|
2011-01-14 16:30:33 +01:00
|
|
|
%token <recptr> RECPTR
|
2017-03-23 13:36:36 +01:00
|
|
|
%token T_WORD
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
/* Keyword tokens. */
|
|
|
|
%token K_BASE_BACKUP
|
|
|
|
%token K_IDENTIFY_SYSTEM
|
2017-01-24 22:59:18 +01:00
|
|
|
%token K_SHOW
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
%token K_START_REPLICATION
|
2014-02-01 04:45:17 +01:00
|
|
|
%token K_CREATE_REPLICATION_SLOT
|
|
|
|
%token K_DROP_REPLICATION_SLOT
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
%token K_TIMELINE_HISTORY
|
2011-01-14 16:30:33 +01:00
|
|
|
%token K_LABEL
|
|
|
|
%token K_PROGRESS
|
2011-01-23 12:21:23 +01:00
|
|
|
%token K_FAST
|
2017-09-01 13:44:14 +02:00
|
|
|
%token K_WAIT
|
2011-02-09 10:59:53 +01:00
|
|
|
%token K_NOWAIT
|
2014-02-27 22:55:57 +01:00
|
|
|
%token K_MAX_RATE
|
2011-01-30 21:30:09 +01:00
|
|
|
%token K_WAL
|
2015-05-12 15:29:10 +02:00
|
|
|
%token K_TABLESPACE_MAP
|
2018-04-03 13:47:16 +02:00
|
|
|
%token K_NOVERIFY_CHECKSUMS
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
%token K_TIMELINE
|
2014-02-01 04:45:17 +01:00
|
|
|
%token K_PHYSICAL
|
2014-03-10 18:50:28 +01:00
|
|
|
%token K_LOGICAL
|
2014-02-01 04:45:17 +01:00
|
|
|
%token K_SLOT
|
2015-09-06 13:17:23 +02:00
|
|
|
%token K_RESERVE_WAL
|
2016-12-08 18:00:00 +01:00
|
|
|
%token K_TEMPORARY
|
2017-03-14 22:13:56 +01:00
|
|
|
%token K_EXPORT_SNAPSHOT
|
|
|
|
%token K_NOEXPORT_SNAPSHOT
|
2017-03-23 13:36:36 +01:00
|
|
|
%token K_USE_SNAPSHOT
|
Generate backup manifests for base backups, and validate them.
A manifest is a JSON document which includes (1) the file name, size,
last modification time, and an optional checksum for each file backed
up, (2) timelines and LSNs for whatever WAL will need to be replayed
to make the backup consistent, and (3) a checksum for the manifest
itself. By default, we use CRC-32C when checksumming data files,
because we are trying to detect corruption and user error, not foil an
adversary. However, pg_basebackup and the server-side BASE_BACKUP
command now have options to select a different algorithm, so users
wanting a cryptographic hash function can select SHA-224, SHA-256,
SHA-384, or SHA-512. Users not wanting file checksums at all can
disable them, or disable generating of the backup manifest altogether.
Using a cryptographic hash function in place of CRC-32C consumes
significantly more CPU cycles, which may slow down backups in some
cases.
A new tool called pg_validatebackup can validate a backup against the
manifest. If no checksums are present, it can still check that the
right files exist and that they have the expected sizes. If checksums
are present, it can also verify that each file has the expected
checksum. Additionally, it calls pg_waldump to verify that the
expected WAL files are present and parseable. Only plain format
backups can be validated directly, but tar format backups can be
validated after extracting them.
Robert Haas, with help, ideas, review, and testing from David Steele,
Stephen Frost, Andrew Dunstan, Rushabh Lathia, Suraj Kharage, Tushar
Ahuja, Rajkumar Raghuwanshi, Mark Dilger, Davinder Singh, Jeevan
Chalke, Amit Kapila, Andres Freund, and Noah Misch.
Discussion: http://postgr.es/m/CA+TgmoZV8dw1H2bzZ9xkKwdrk8+XYa+DC9H=F7heO2zna5T6qg@mail.gmail.com
2020-04-03 20:59:47 +02:00
|
|
|
%token K_MANIFEST
|
|
|
|
%token K_MANIFEST_CHECKSUMS
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
%type <node> command
|
2015-05-12 15:29:10 +02:00
|
|
|
%type <node> base_backup start_replication start_logical_replication
|
|
|
|
create_replication_slot drop_replication_slot identify_system
|
2017-03-23 13:36:36 +01:00
|
|
|
timeline_history show sql_cmd
|
2011-01-23 23:39:18 +01:00
|
|
|
%type <list> base_backup_opt_list
|
|
|
|
%type <defelt> base_backup_opt
|
2013-08-15 05:18:49 +02:00
|
|
|
%type <uintval> opt_timeline
|
2014-03-10 18:50:28 +01:00
|
|
|
%type <list> plugin_options plugin_opt_list
|
|
|
|
%type <defelt> plugin_opt_elem
|
|
|
|
%type <node> plugin_opt_arg
|
2017-01-24 22:59:18 +01:00
|
|
|
%type <str> opt_slot var_name
|
2017-03-14 22:13:56 +01:00
|
|
|
%type <boolval> opt_temporary
|
|
|
|
%type <list> create_slot_opt_list
|
|
|
|
%type <defelt> create_slot_opt
|
2014-02-02 18:51:14 +01:00
|
|
|
|
2011-01-14 16:30:33 +01:00
|
|
|
%%
|
|
|
|
|
|
|
|
firstcmd: command opt_semicolon
|
|
|
|
{
|
|
|
|
replication_parse_result = $1;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_semicolon: ';'
|
|
|
|
| /* EMPTY */
|
|
|
|
;
|
|
|
|
|
|
|
|
command:
|
|
|
|
identify_system
|
|
|
|
| base_backup
|
|
|
|
| start_replication
|
2014-03-10 18:50:28 +01:00
|
|
|
| start_logical_replication
|
2014-02-01 04:45:17 +01:00
|
|
|
| create_replication_slot
|
|
|
|
| drop_replication_slot
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
| timeline_history
|
2017-01-24 22:59:18 +01:00
|
|
|
| show
|
2017-03-23 13:36:36 +01:00
|
|
|
| sql_cmd
|
2011-01-14 16:30:33 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IDENTIFY_SYSTEM
|
|
|
|
*/
|
|
|
|
identify_system:
|
|
|
|
K_IDENTIFY_SYSTEM
|
|
|
|
{
|
|
|
|
$$ = (Node *) makeNode(IdentifySystemCmd);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2017-01-24 22:59:18 +01:00
|
|
|
/*
|
|
|
|
* SHOW setting
|
|
|
|
*/
|
|
|
|
show:
|
|
|
|
K_SHOW var_name
|
|
|
|
{
|
|
|
|
VariableShowStmt *n = makeNode(VariableShowStmt);
|
|
|
|
n->name = $2;
|
|
|
|
$$ = (Node *) n;
|
|
|
|
}
|
|
|
|
|
|
|
|
var_name: IDENT { $$ = $1; }
|
|
|
|
| var_name '.' IDENT
|
|
|
|
{ $$ = psprintf("%s.%s", $1, $3); }
|
|
|
|
;
|
|
|
|
|
2011-01-14 16:30:33 +01:00
|
|
|
/*
|
2015-05-12 15:29:10 +02:00
|
|
|
* BASE_BACKUP [LABEL '<label>'] [PROGRESS] [FAST] [WAL] [NOWAIT]
|
2018-04-03 13:47:16 +02:00
|
|
|
* [MAX_RATE %d] [TABLESPACE_MAP] [NOVERIFY_CHECKSUMS]
|
Generate backup manifests for base backups, and validate them.
A manifest is a JSON document which includes (1) the file name, size,
last modification time, and an optional checksum for each file backed
up, (2) timelines and LSNs for whatever WAL will need to be replayed
to make the backup consistent, and (3) a checksum for the manifest
itself. By default, we use CRC-32C when checksumming data files,
because we are trying to detect corruption and user error, not foil an
adversary. However, pg_basebackup and the server-side BASE_BACKUP
command now have options to select a different algorithm, so users
wanting a cryptographic hash function can select SHA-224, SHA-256,
SHA-384, or SHA-512. Users not wanting file checksums at all can
disable them, or disable generating of the backup manifest altogether.
Using a cryptographic hash function in place of CRC-32C consumes
significantly more CPU cycles, which may slow down backups in some
cases.
A new tool called pg_validatebackup can validate a backup against the
manifest. If no checksums are present, it can still check that the
right files exist and that they have the expected sizes. If checksums
are present, it can also verify that each file has the expected
checksum. Additionally, it calls pg_waldump to verify that the
expected WAL files are present and parseable. Only plain format
backups can be validated directly, but tar format backups can be
validated after extracting them.
Robert Haas, with help, ideas, review, and testing from David Steele,
Stephen Frost, Andrew Dunstan, Rushabh Lathia, Suraj Kharage, Tushar
Ahuja, Rajkumar Raghuwanshi, Mark Dilger, Davinder Singh, Jeevan
Chalke, Amit Kapila, Andres Freund, and Noah Misch.
Discussion: http://postgr.es/m/CA+TgmoZV8dw1H2bzZ9xkKwdrk8+XYa+DC9H=F7heO2zna5T6qg@mail.gmail.com
2020-04-03 20:59:47 +02:00
|
|
|
* [MANIFEST %s] [MANIFEST_CHECKSUMS %s]
|
2011-01-14 16:30:33 +01:00
|
|
|
*/
|
|
|
|
base_backup:
|
2011-01-23 23:39:18 +01:00
|
|
|
K_BASE_BACKUP base_backup_opt_list
|
2011-01-14 16:30:33 +01:00
|
|
|
{
|
2016-12-23 18:00:00 +01:00
|
|
|
BaseBackupCmd *cmd = makeNode(BaseBackupCmd);
|
2011-01-23 23:39:18 +01:00
|
|
|
cmd->options = $2;
|
2011-01-14 16:30:33 +01:00
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2014-02-02 18:51:14 +01:00
|
|
|
base_backup_opt_list:
|
|
|
|
base_backup_opt_list base_backup_opt
|
|
|
|
{ $$ = lappend($1, $2); }
|
|
|
|
| /* EMPTY */
|
|
|
|
{ $$ = NIL; }
|
|
|
|
;
|
2011-01-23 23:39:18 +01:00
|
|
|
|
|
|
|
base_backup_opt:
|
|
|
|
K_LABEL SCONST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("label",
|
2016-09-06 18:00:00 +02:00
|
|
|
(Node *)makeString($2), -1);
|
2011-01-23 23:39:18 +01:00
|
|
|
}
|
|
|
|
| K_PROGRESS
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("progress",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2011-01-23 23:39:18 +01:00
|
|
|
}
|
|
|
|
| K_FAST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("fast",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2011-01-23 23:39:18 +01:00
|
|
|
}
|
2011-01-30 21:30:09 +01:00
|
|
|
| K_WAL
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("wal",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2011-01-30 21:30:09 +01:00
|
|
|
}
|
2011-02-09 10:59:53 +01:00
|
|
|
| K_NOWAIT
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("nowait",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2011-02-09 10:59:53 +01:00
|
|
|
}
|
2014-02-27 22:55:57 +01:00
|
|
|
| K_MAX_RATE UCONST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("max_rate",
|
2016-09-06 18:00:00 +02:00
|
|
|
(Node *)makeInteger($2), -1);
|
2014-02-27 22:55:57 +01:00
|
|
|
}
|
2015-05-12 15:29:10 +02:00
|
|
|
| K_TABLESPACE_MAP
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("tablespace_map",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2015-05-12 15:29:10 +02:00
|
|
|
}
|
2018-04-03 13:47:16 +02:00
|
|
|
| K_NOVERIFY_CHECKSUMS
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("noverify_checksums",
|
|
|
|
(Node *)makeInteger(true), -1);
|
|
|
|
}
|
Generate backup manifests for base backups, and validate them.
A manifest is a JSON document which includes (1) the file name, size,
last modification time, and an optional checksum for each file backed
up, (2) timelines and LSNs for whatever WAL will need to be replayed
to make the backup consistent, and (3) a checksum for the manifest
itself. By default, we use CRC-32C when checksumming data files,
because we are trying to detect corruption and user error, not foil an
adversary. However, pg_basebackup and the server-side BASE_BACKUP
command now have options to select a different algorithm, so users
wanting a cryptographic hash function can select SHA-224, SHA-256,
SHA-384, or SHA-512. Users not wanting file checksums at all can
disable them, or disable generating of the backup manifest altogether.
Using a cryptographic hash function in place of CRC-32C consumes
significantly more CPU cycles, which may slow down backups in some
cases.
A new tool called pg_validatebackup can validate a backup against the
manifest. If no checksums are present, it can still check that the
right files exist and that they have the expected sizes. If checksums
are present, it can also verify that each file has the expected
checksum. Additionally, it calls pg_waldump to verify that the
expected WAL files are present and parseable. Only plain format
backups can be validated directly, but tar format backups can be
validated after extracting them.
Robert Haas, with help, ideas, review, and testing from David Steele,
Stephen Frost, Andrew Dunstan, Rushabh Lathia, Suraj Kharage, Tushar
Ahuja, Rajkumar Raghuwanshi, Mark Dilger, Davinder Singh, Jeevan
Chalke, Amit Kapila, Andres Freund, and Noah Misch.
Discussion: http://postgr.es/m/CA+TgmoZV8dw1H2bzZ9xkKwdrk8+XYa+DC9H=F7heO2zna5T6qg@mail.gmail.com
2020-04-03 20:59:47 +02:00
|
|
|
| K_MANIFEST SCONST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("manifest",
|
|
|
|
(Node *)makeString($2), -1);
|
|
|
|
}
|
|
|
|
| K_MANIFEST_CHECKSUMS SCONST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("manifest_checksums",
|
|
|
|
(Node *)makeString($2), -1);
|
|
|
|
}
|
2011-01-30 21:30:09 +01:00
|
|
|
;
|
2011-01-14 16:30:33 +01:00
|
|
|
|
2014-02-01 04:45:17 +01:00
|
|
|
create_replication_slot:
|
2016-12-08 18:00:00 +01:00
|
|
|
/* CREATE_REPLICATION_SLOT slot TEMPORARY PHYSICAL RESERVE_WAL */
|
2017-03-14 22:13:56 +01:00
|
|
|
K_CREATE_REPLICATION_SLOT IDENT opt_temporary K_PHYSICAL create_slot_opt_list
|
2014-02-01 04:45:17 +01:00
|
|
|
{
|
|
|
|
CreateReplicationSlotCmd *cmd;
|
|
|
|
cmd = makeNode(CreateReplicationSlotCmd);
|
|
|
|
cmd->kind = REPLICATION_KIND_PHYSICAL;
|
|
|
|
cmd->slotname = $2;
|
2016-12-08 18:00:00 +01:00
|
|
|
cmd->temporary = $3;
|
2017-03-14 22:13:56 +01:00
|
|
|
cmd->options = $5;
|
2014-02-01 04:45:17 +01:00
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
2016-12-08 18:00:00 +01:00
|
|
|
/* CREATE_REPLICATION_SLOT slot TEMPORARY LOGICAL plugin */
|
2017-03-14 22:13:56 +01:00
|
|
|
| K_CREATE_REPLICATION_SLOT IDENT opt_temporary K_LOGICAL IDENT create_slot_opt_list
|
2014-03-10 18:50:28 +01:00
|
|
|
{
|
|
|
|
CreateReplicationSlotCmd *cmd;
|
|
|
|
cmd = makeNode(CreateReplicationSlotCmd);
|
|
|
|
cmd->kind = REPLICATION_KIND_LOGICAL;
|
|
|
|
cmd->slotname = $2;
|
2016-12-08 18:00:00 +01:00
|
|
|
cmd->temporary = $3;
|
|
|
|
cmd->plugin = $5;
|
2017-03-14 22:13:56 +01:00
|
|
|
cmd->options = $6;
|
2014-03-10 18:50:28 +01:00
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
2014-02-01 04:45:17 +01:00
|
|
|
;
|
|
|
|
|
2017-03-14 22:13:56 +01:00
|
|
|
create_slot_opt_list:
|
|
|
|
create_slot_opt_list create_slot_opt
|
|
|
|
{ $$ = lappend($1, $2); }
|
|
|
|
| /* EMPTY */
|
|
|
|
{ $$ = NIL; }
|
|
|
|
;
|
|
|
|
|
|
|
|
create_slot_opt:
|
|
|
|
K_EXPORT_SNAPSHOT
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("export_snapshot",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2017-03-14 22:13:56 +01:00
|
|
|
}
|
|
|
|
| K_NOEXPORT_SNAPSHOT
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("export_snapshot",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(false), -1);
|
2017-03-14 22:13:56 +01:00
|
|
|
}
|
2017-03-23 13:36:36 +01:00
|
|
|
| K_USE_SNAPSHOT
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("use_snapshot",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2017-03-23 13:36:36 +01:00
|
|
|
}
|
2017-03-14 22:13:56 +01:00
|
|
|
| K_RESERVE_WAL
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("reserve_wal",
|
2017-08-16 06:22:32 +02:00
|
|
|
(Node *)makeInteger(true), -1);
|
2017-03-14 22:13:56 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2014-03-10 18:50:28 +01:00
|
|
|
/* DROP_REPLICATION_SLOT slot */
|
2014-02-01 04:45:17 +01:00
|
|
|
drop_replication_slot:
|
|
|
|
K_DROP_REPLICATION_SLOT IDENT
|
|
|
|
{
|
|
|
|
DropReplicationSlotCmd *cmd;
|
|
|
|
cmd = makeNode(DropReplicationSlotCmd);
|
|
|
|
cmd->slotname = $2;
|
2017-09-01 13:44:14 +02:00
|
|
|
cmd->wait = false;
|
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
| K_DROP_REPLICATION_SLOT IDENT K_WAIT
|
|
|
|
{
|
|
|
|
DropReplicationSlotCmd *cmd;
|
|
|
|
cmd = makeNode(DropReplicationSlotCmd);
|
|
|
|
cmd->slotname = $2;
|
|
|
|
cmd->wait = true;
|
2014-02-01 04:45:17 +01:00
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2011-01-14 16:30:33 +01:00
|
|
|
/*
|
2014-02-01 04:45:17 +01:00
|
|
|
* START_REPLICATION [SLOT slot] [PHYSICAL] %X/%X [TIMELINE %d]
|
2011-01-14 16:30:33 +01:00
|
|
|
*/
|
|
|
|
start_replication:
|
2014-02-01 04:45:17 +01:00
|
|
|
K_START_REPLICATION opt_slot opt_physical RECPTR opt_timeline
|
2011-01-14 16:30:33 +01:00
|
|
|
{
|
|
|
|
StartReplicationCmd *cmd;
|
|
|
|
|
|
|
|
cmd = makeNode(StartReplicationCmd);
|
2014-02-01 04:45:17 +01:00
|
|
|
cmd->kind = REPLICATION_KIND_PHYSICAL;
|
|
|
|
cmd->slotname = $2;
|
|
|
|
cmd->startpoint = $4;
|
|
|
|
cmd->timeline = $5;
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2014-03-10 18:50:28 +01:00
|
|
|
/* START_REPLICATION SLOT slot LOGICAL %X/%X options */
|
|
|
|
start_logical_replication:
|
|
|
|
K_START_REPLICATION K_SLOT IDENT K_LOGICAL RECPTR plugin_options
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
{
|
2014-03-10 18:50:28 +01:00
|
|
|
StartReplicationCmd *cmd;
|
|
|
|
cmd = makeNode(StartReplicationCmd);
|
2015-03-31 14:12:27 +02:00
|
|
|
cmd->kind = REPLICATION_KIND_LOGICAL;
|
2014-03-10 18:50:28 +01:00
|
|
|
cmd->slotname = $3;
|
|
|
|
cmd->startpoint = $5;
|
|
|
|
cmd->options = $6;
|
|
|
|
$$ = (Node *) cmd;
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
/*
|
|
|
|
* TIMELINE_HISTORY %d
|
|
|
|
*/
|
|
|
|
timeline_history:
|
2013-08-15 05:18:49 +02:00
|
|
|
K_TIMELINE_HISTORY UCONST
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
{
|
|
|
|
TimeLineHistoryCmd *cmd;
|
|
|
|
|
|
|
|
if ($2 <= 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2020-01-30 17:32:04 +01:00
|
|
|
errmsg("invalid timeline %u", $2)));
|
Allow a streaming replication standby to follow a timeline switch.
Before this patch, streaming replication would refuse to start replicating
if the timeline in the primary doesn't exactly match the standby. The
situation where it doesn't match is when you have a master, and two
standbys, and you promote one of the standbys to become new master.
Promoting bumps up the timeline ID, and after that bump, the other standby
would refuse to continue.
There's significantly more timeline related logic in streaming replication
now. First of all, when a standby connects to primary, it will ask the
primary for any timeline history files that are missing from the standby.
The missing files are sent using a new replication command TIMELINE_HISTORY,
and stored in standby's pg_xlog directory. Using the timeline history files,
the standby can follow the latest timeline present in the primary
(recovery_target_timeline='latest'), just as it can follow new timelines
appearing in an archive directory.
START_REPLICATION now takes a TIMELINE parameter, to specify exactly which
timeline to stream WAL from. This allows the standby to request the primary
to send over WAL that precedes the promotion. The replication protocol is
changed slightly (in a backwards-compatible way although there's little hope
of streaming replication working across major versions anyway), to allow
replication to stop when the end of timeline reached, putting the walsender
back into accepting a replication command.
Many thanks to Amit Kapila for testing and reviewing various versions of
this patch.
2012-12-13 18:00:00 +01:00
|
|
|
|
|
|
|
cmd = makeNode(TimeLineHistoryCmd);
|
|
|
|
cmd->timeline = $2;
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
2014-02-01 04:45:17 +01:00
|
|
|
|
2014-02-02 18:51:14 +01:00
|
|
|
opt_physical:
|
|
|
|
K_PHYSICAL
|
|
|
|
| /* EMPTY */
|
|
|
|
;
|
2014-02-01 04:45:17 +01:00
|
|
|
|
2016-12-08 18:00:00 +01:00
|
|
|
opt_temporary:
|
|
|
|
K_TEMPORARY { $$ = true; }
|
|
|
|
| /* EMPTY */ { $$ = false; }
|
|
|
|
;
|
|
|
|
|
2014-02-02 18:51:14 +01:00
|
|
|
opt_slot:
|
|
|
|
K_SLOT IDENT
|
|
|
|
{ $$ = $2; }
|
|
|
|
| /* EMPTY */
|
|
|
|
{ $$ = NULL; }
|
|
|
|
;
|
2014-02-01 04:45:17 +01:00
|
|
|
|
2014-03-10 18:50:28 +01:00
|
|
|
opt_timeline:
|
|
|
|
K_TIMELINE UCONST
|
|
|
|
{
|
|
|
|
if ($2 <= 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2020-01-30 17:32:04 +01:00
|
|
|
errmsg("invalid timeline %u", $2)));
|
2014-03-10 18:50:28 +01:00
|
|
|
$$ = $2;
|
|
|
|
}
|
|
|
|
| /* EMPTY */ { $$ = 0; }
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
plugin_options:
|
|
|
|
'(' plugin_opt_list ')' { $$ = $2; }
|
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
|
|
|
;
|
|
|
|
|
|
|
|
plugin_opt_list:
|
|
|
|
plugin_opt_elem
|
|
|
|
{
|
|
|
|
$$ = list_make1($1);
|
|
|
|
}
|
|
|
|
| plugin_opt_list ',' plugin_opt_elem
|
|
|
|
{
|
|
|
|
$$ = lappend($1, $3);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
plugin_opt_elem:
|
|
|
|
IDENT plugin_opt_arg
|
|
|
|
{
|
2016-09-06 18:00:00 +02:00
|
|
|
$$ = makeDefElem($1, $2, -1);
|
2014-03-10 18:50:28 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
plugin_opt_arg:
|
|
|
|
SCONST { $$ = (Node *) makeString($1); }
|
|
|
|
| /* EMPTY */ { $$ = NULL; }
|
|
|
|
;
|
2017-03-23 13:36:36 +01:00
|
|
|
|
|
|
|
sql_cmd:
|
|
|
|
IDENT { $$ = (Node *) make_sqlcmd(); }
|
|
|
|
;
|
2011-01-14 16:30:33 +01:00
|
|
|
%%
|
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
static SQLCmd *
|
|
|
|
make_sqlcmd(void)
|
|
|
|
{
|
|
|
|
SQLCmd *cmd = makeNode(SQLCmd);
|
|
|
|
int tok;
|
|
|
|
|
|
|
|
/* Just move lexer to the end of command. */
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
tok = yylex();
|
|
|
|
if (tok == ';' || tok == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return cmd;
|
|
|
|
}
|
|
|
|
|
2011-01-14 16:30:33 +01:00
|
|
|
#include "repl_scanner.c"
|