2011-10-26 20:13:33 +02:00
|
|
|
#include "access/xlogdefs.h"
|
|
|
|
|
|
|
|
/*
|
2012-05-25 11:36:22 +02:00
|
|
|
* Called before trying to read more data or when a segment is
|
|
|
|
* finished. Return true to stop streaming.
|
2011-10-26 20:13:33 +02:00
|
|
|
*/
|
2012-06-10 21:20:04 +02:00
|
|
|
typedef bool (*stream_stop_callback) (XLogRecPtr segendpos, uint32 timeline, bool segment_finished);
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
extern bool ReceiveXlogStream(PGconn *conn,
|
2012-06-10 21:20:04 +02:00
|
|
|
XLogRecPtr startpos,
|
|
|
|
uint32 timeline,
|
|
|
|
char *sysidentifier,
|
|
|
|
char *basedir,
|
|
|
|
stream_stop_callback stream_stop,
|
|
|
|
int standby_message_timeout,
|
Make pg_receivexlog and pg_basebackup -X stream work across timeline switches.
This mirrors the changes done earlier to the server in standby mode. When
receivelog reaches the end of a timeline, as reported by the server, it
fetches the timeline history file of the next timeline, and restarts
streaming from the new timeline by issuing a new START_STREAMING command.
When pg_receivexlog crosses a timeline, it leaves the .partial suffix on the
last segment on the old timeline. This helps you to tell apart a partial
segment left in the directory because of a timeline switch, and a completed
segment. If you just follow a single server, it won't make a difference, but
it can be significant in more complicated scenarios where new WAL is still
generated on the old timeline.
This includes two small changes to the streaming replication protocol:
First, when you reach the end of timeline while streaming, the server now
sends the TLI of the next timeline in the server's history to the client.
pg_receivexlog uses that as the next timeline, so that it doesn't need to
parse the timeline history file like a standby server does. Second, when
BASE_BACKUP command sends the begin and end WAL positions, it now also sends
the timeline IDs corresponding the positions.
2013-01-17 19:23:00 +01:00
|
|
|
char *partial_suffix);
|