2010-01-15 10:19:10 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* walreceiver.h
|
|
|
|
* Exports from replication/walreceiverfuncs.c.
|
|
|
|
*
|
|
|
|
* Portions Copyright (c) 2010-2010, PostgreSQL Global Development Group
|
|
|
|
*
|
2010-02-03 10:47:19 +01:00
|
|
|
* $PostgreSQL: pgsql/src/include/replication/walreceiver.h,v 1.6 2010/02/03 09:47:19 heikki Exp $
|
2010-01-15 10:19:10 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef _WALRECEIVER_H
|
|
|
|
#define _WALRECEIVER_H
|
|
|
|
|
2010-01-20 10:16:24 +01:00
|
|
|
#include "access/xlogdefs.h"
|
2010-01-15 10:19:10 +01:00
|
|
|
#include "storage/spin.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* MAXCONNINFO: maximum size of a connection string.
|
|
|
|
*
|
|
|
|
* XXX: Should this move to pg_config_manual.h?
|
|
|
|
*/
|
|
|
|
#define MAXCONNINFO 1024
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Values for WalRcv->walRcvState.
|
|
|
|
*/
|
|
|
|
typedef enum
|
|
|
|
{
|
Make standby server continuously retry restoring the next WAL segment with
restore_command, if the connection to the primary server is lost. This
ensures that the standby can recover automatically, if the connection is
lost for a long time and standby falls behind so much that the required
WAL segments have been archived and deleted in the master.
This also makes standby_mode useful without streaming replication; the
server will keep retrying restore_command every few seconds until the
trigger file is found. That's the same basic functionality pg_standby
offers, but without the bells and whistles.
To implement that, refactor the ReadRecord/FetchRecord functions. The
FetchRecord() function introduced in the original streaming replication
patch is removed, and all the retry logic is now in a new function called
XLogReadPage(). XLogReadPage() is now responsible for executing
restore_command, launching walreceiver, and waiting for new WAL to arrive
from primary, as required.
This also changes the life cycle of walreceiver. When launched, it now only
tries to connect to the master once, and exits if the connection fails, or
is lost during streaming for any reason. The startup process detects the
death, and re-launches walreceiver if necessary.
2010-01-27 16:27:51 +01:00
|
|
|
WALRCV_STOPPED, /* stopped and mustn't start up again */
|
|
|
|
WALRCV_STARTING, /* launched, but the process hasn't initialized yet */
|
|
|
|
WALRCV_RUNNING, /* walreceiver is running */
|
|
|
|
WALRCV_STOPPING /* requested to stop, but still running */
|
2010-01-15 10:19:10 +01:00
|
|
|
} WalRcvState;
|
|
|
|
|
|
|
|
/* Shared memory area for management of walreceiver process */
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* connection string; is used for walreceiver to connect with
|
|
|
|
* the primary.
|
|
|
|
*/
|
|
|
|
char conninfo[MAXCONNINFO];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PID of currently active walreceiver process, and the current state.
|
|
|
|
*/
|
|
|
|
pid_t pid;
|
|
|
|
WalRcvState walRcvState;
|
Make standby server continuously retry restoring the next WAL segment with
restore_command, if the connection to the primary server is lost. This
ensures that the standby can recover automatically, if the connection is
lost for a long time and standby falls behind so much that the required
WAL segments have been archived and deleted in the master.
This also makes standby_mode useful without streaming replication; the
server will keep retrying restore_command every few seconds until the
trigger file is found. That's the same basic functionality pg_standby
offers, but without the bells and whistles.
To implement that, refactor the ReadRecord/FetchRecord functions. The
FetchRecord() function introduced in the original streaming replication
patch is removed, and all the retry logic is now in a new function called
XLogReadPage(). XLogReadPage() is now responsible for executing
restore_command, launching walreceiver, and waiting for new WAL to arrive
from primary, as required.
This also changes the life cycle of walreceiver. When launched, it now only
tries to connect to the master once, and exits if the connection fails, or
is lost during streaming for any reason. The startup process detects the
death, and re-launches walreceiver if necessary.
2010-01-27 16:27:51 +01:00
|
|
|
pg_time_t startTime;
|
2010-01-15 10:19:10 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* receivedUpto-1 is the last byte position that has been already
|
|
|
|
* received. When startup process starts the walreceiver, it sets this
|
|
|
|
* to the point where it wants the streaming to begin. After that,
|
|
|
|
* walreceiver updates this whenever it flushes the received WAL.
|
|
|
|
*/
|
|
|
|
XLogRecPtr receivedUpto;
|
|
|
|
|
|
|
|
slock_t mutex; /* locks shared variables shown above */
|
|
|
|
} WalRcvData;
|
|
|
|
|
2010-01-20 19:54:27 +01:00
|
|
|
extern WalRcvData *WalRcv;
|
2010-01-15 10:19:10 +01:00
|
|
|
|
2010-01-20 10:16:24 +01:00
|
|
|
/* libpqwalreceiver hooks */
|
|
|
|
typedef bool (*walrcv_connect_type) (char *conninfo, XLogRecPtr startpoint);
|
|
|
|
extern PGDLLIMPORT walrcv_connect_type walrcv_connect;
|
|
|
|
|
2010-02-03 10:47:19 +01:00
|
|
|
typedef bool (*walrcv_receive_type) (int timeout, unsigned char *type,
|
|
|
|
char **buffer, int *len);
|
2010-01-20 10:16:24 +01:00
|
|
|
extern PGDLLIMPORT walrcv_receive_type walrcv_receive;
|
|
|
|
|
|
|
|
typedef void (*walrcv_disconnect_type) (void);
|
|
|
|
extern PGDLLIMPORT walrcv_disconnect_type walrcv_disconnect;
|
|
|
|
|
|
|
|
extern void WalReceiverMain(void);
|
2010-01-15 10:19:10 +01:00
|
|
|
extern Size WalRcvShmemSize(void);
|
|
|
|
extern void WalRcvShmemInit(void);
|
Make standby server continuously retry restoring the next WAL segment with
restore_command, if the connection to the primary server is lost. This
ensures that the standby can recover automatically, if the connection is
lost for a long time and standby falls behind so much that the required
WAL segments have been archived and deleted in the master.
This also makes standby_mode useful without streaming replication; the
server will keep retrying restore_command every few seconds until the
trigger file is found. That's the same basic functionality pg_standby
offers, but without the bells and whistles.
To implement that, refactor the ReadRecord/FetchRecord functions. The
FetchRecord() function introduced in the original streaming replication
patch is removed, and all the retry logic is now in a new function called
XLogReadPage(). XLogReadPage() is now responsible for executing
restore_command, launching walreceiver, and waiting for new WAL to arrive
from primary, as required.
This also changes the life cycle of walreceiver. When launched, it now only
tries to connect to the master once, and exits if the connection fails, or
is lost during streaming for any reason. The startup process detects the
death, and re-launches walreceiver if necessary.
2010-01-27 16:27:51 +01:00
|
|
|
extern void ShutdownWalRcv(void);
|
2010-01-15 10:19:10 +01:00
|
|
|
extern bool WalRcvInProgress(void);
|
|
|
|
extern XLogRecPtr WaitNextXLogAvailable(XLogRecPtr recptr, bool *finished);
|
|
|
|
extern void RequestXLogStreaming(XLogRecPtr recptr, const char *conninfo);
|
|
|
|
extern XLogRecPtr GetWalRcvWriteRecPtr(void);
|
|
|
|
|
|
|
|
#endif /* _WALRECEIVER_H */
|