2011-01-14 16:30:33 +01:00
|
|
|
%{
|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* repl_gram.y - Parser for the replication commands
|
|
|
|
*
|
2013-01-01 23:15:01 +01:00
|
|
|
* Portions Copyright (c) 1996-2013, 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;
|
|
|
|
|
|
|
|
/* Location tracking support --- simpler than bison's default */
|
|
|
|
#define YYLLOC_DEFAULT(Current, Rhs, N) \
|
|
|
|
do { \
|
|
|
|
if (N) \
|
|
|
|
(Current) = (Rhs)[1]; \
|
|
|
|
else \
|
|
|
|
(Current) = (Rhs)[0]; \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
|
|
|
|
#define parser_yyerror(msg) replication_yyerror(msg, yyscanner)
|
|
|
|
#define parser_errposition(pos) replication_scanner_errposition(pos)
|
|
|
|
|
|
|
|
%}
|
|
|
|
|
|
|
|
%expect 0
|
|
|
|
%name-prefix="replication_yy"
|
|
|
|
|
|
|
|
%union {
|
|
|
|
char *str;
|
|
|
|
bool boolval;
|
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
|
|
|
int32 intval;
|
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 */
|
|
|
|
%token <str> SCONST
|
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 <intval> ICONST
|
2011-01-14 16:30:33 +01:00
|
|
|
%token <recptr> RECPTR
|
|
|
|
|
|
|
|
/* Keyword tokens. */
|
|
|
|
%token K_BASE_BACKUP
|
|
|
|
%token K_IDENTIFY_SYSTEM
|
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
|
|
|
|
%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
|
2011-02-09 10:59:53 +01:00
|
|
|
%token K_NOWAIT
|
2011-01-30 21:30:09 +01:00
|
|
|
%token K_WAL
|
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
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
%type <node> command
|
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
|
|
|
%type <node> base_backup start_replication identify_system timeline_history
|
2011-01-23 23:39:18 +01:00
|
|
|
%type <list> base_backup_opt_list
|
|
|
|
%type <defelt> base_backup_opt
|
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
|
|
|
%type <intval> opt_timeline
|
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
|
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
|
2011-01-14 16:30:33 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IDENTIFY_SYSTEM
|
|
|
|
*/
|
|
|
|
identify_system:
|
|
|
|
K_IDENTIFY_SYSTEM
|
|
|
|
{
|
|
|
|
$$ = (Node *) makeNode(IdentifySystemCmd);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
2011-02-09 10:59:53 +01:00
|
|
|
* BASE_BACKUP [LABEL '<label>'] [PROGRESS] [FAST] [WAL] [NOWAIT]
|
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
|
|
|
{
|
|
|
|
BaseBackupCmd *cmd = (BaseBackupCmd *) makeNode(BaseBackupCmd);
|
2011-01-23 23:39:18 +01:00
|
|
|
cmd->options = $2;
|
2011-01-14 16:30:33 +01:00
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2011-01-23 23:39:18 +01:00
|
|
|
base_backup_opt_list: base_backup_opt_list base_backup_opt { $$ = lappend($1, $2); }
|
2011-11-01 20:50:00 +01:00
|
|
|
| /* EMPTY */ { $$ = NIL; }
|
2011-01-23 23:39:18 +01:00
|
|
|
|
|
|
|
base_backup_opt:
|
|
|
|
K_LABEL SCONST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("label",
|
|
|
|
(Node *)makeString($2));
|
|
|
|
}
|
|
|
|
| K_PROGRESS
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("progress",
|
|
|
|
(Node *)makeInteger(TRUE));
|
|
|
|
}
|
|
|
|
| K_FAST
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("fast",
|
|
|
|
(Node *)makeInteger(TRUE));
|
|
|
|
}
|
2011-01-30 21:30:09 +01:00
|
|
|
| K_WAL
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("wal",
|
|
|
|
(Node *)makeInteger(TRUE));
|
|
|
|
}
|
2011-02-09 10:59:53 +01:00
|
|
|
| K_NOWAIT
|
|
|
|
{
|
|
|
|
$$ = makeDefElem("nowait",
|
|
|
|
(Node *)makeInteger(TRUE));
|
|
|
|
}
|
2011-01-30 21:30:09 +01:00
|
|
|
;
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
/*
|
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
|
|
|
* START_REPLICATION %X/%X [TIMELINE %d]
|
2011-01-14 16:30:33 +01:00
|
|
|
*/
|
|
|
|
start_replication:
|
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
|
|
|
K_START_REPLICATION RECPTR opt_timeline
|
2011-01-14 16:30:33 +01:00
|
|
|
{
|
|
|
|
StartReplicationCmd *cmd;
|
|
|
|
|
|
|
|
cmd = makeNode(StartReplicationCmd);
|
|
|
|
cmd->startpoint = $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->timeline = $3;
|
|
|
|
|
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_timeline:
|
|
|
|
K_TIMELINE ICONST
|
|
|
|
{
|
|
|
|
if ($2 <= 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
(errmsg("invalid timeline %d", $2))));
|
|
|
|
$$ = $2;
|
|
|
|
}
|
|
|
|
| /* nothing */ { $$ = 0; }
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* TIMELINE_HISTORY %d
|
|
|
|
*/
|
|
|
|
timeline_history:
|
|
|
|
K_TIMELINE_HISTORY ICONST
|
|
|
|
{
|
|
|
|
TimeLineHistoryCmd *cmd;
|
|
|
|
|
|
|
|
if ($2 <= 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
(errmsg("invalid timeline %d", $2))));
|
|
|
|
|
|
|
|
cmd = makeNode(TimeLineHistoryCmd);
|
|
|
|
cmd->timeline = $2;
|
2011-01-14 16:30:33 +01:00
|
|
|
|
|
|
|
$$ = (Node *) cmd;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
%%
|
|
|
|
|
|
|
|
#include "repl_scanner.c"
|