database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00
Code Activity

Make the streaming replication protocol messages architecture-independent.

Browse Source 
We used to send structs wrapped in CopyData messages, which works as long as
the client and server agree on things like endianess, timestamp format and
alignment. That's good enough for running a standby server, which has to run
on the same platform anyway, but it's useful for tools like pg_receivexlog
to work across platforms.

This breaks protocol compatibility of streaming replication, but we never
promised that to be compatible across versions, anyway.
This commit is contained in:
Heikki Linnakangas
2012-11-07 18:59:12 +02:00
parent ed5699dd1b
commit add6c3179a
7 changed files with 384 additions and 367 deletions
Download Patch File Download Diff File Expand all files Collapse all files

128
src/include/replication/walprotocol.h
View File

@@ -1,128 +0,0 @@
/*-------------------------------------------------------------------------
*
* walprotocol.h
* Definitions relevant to the streaming WAL transmission protocol.
*
* Portions Copyright (c) 2010-2012, PostgreSQL Global Development Group
*
* src/include/replication/walprotocol.h
*
*-------------------------------------------------------------------------
*/
#ifndef _WALPROTOCOL_H
#define _WALPROTOCOL_H
#include "access/xlogdefs.h"
#include "datatype/timestamp.h"
/*
* All messages from WalSender must contain these fields to allow us to
* correctly calculate the replication delay.
*/
typedef struct
{
/* Current end of WAL on the sender */
XLogRecPtr walEnd;
/* Sender's system clock at the time of transmission */
TimestampTz sendTime;
/*
* If replyRequested is set, the client should reply immediately to this
* message, to avoid a timeout disconnect.
*/
bool replyRequested;
} WalSndrMessage;
/*
* Header for a WAL data message (message type 'w'). This is wrapped within
* a CopyData message at the FE/BE protocol level.
*
* The header is followed by actual WAL data. Note that the data length is
* not specified in the header --- it's just whatever remains in the message.
*
* walEnd and sendTime are not essential data, but are provided in case
* the receiver wants to adjust its behavior depending on how far behind
* it is.
*/
typedef struct
{
/* WAL start location of the data included in this message */
XLogRecPtr dataStart;
/* Current end of WAL on the sender */
XLogRecPtr walEnd;
/* Sender's system clock at the time of transmission */
TimestampTz sendTime;
} WalDataMessageHeader;
/*
* Keepalive message from primary (message type 'k'). (lowercase k)
* This is wrapped within a CopyData message at the FE/BE protocol level.
*
* Note that the data length is not specified here.
*/
typedef WalSndrMessage PrimaryKeepaliveMessage;
/*
* Reply message from standby (message type 'r'). This is wrapped within
* a CopyData message at the FE/BE protocol level.
*
* Note that the data length is not specified here.
*/
typedef struct
{
/*
* The xlog locations that have been written, flushed, and applied by
* standby-side. These may be invalid if the standby-side is unable to or
* chooses not to report these.
*/
XLogRecPtr write;
XLogRecPtr flush;
XLogRecPtr apply;
/* Sender's system clock at the time of transmission */
TimestampTz sendTime;
/*
* If replyRequested is set, the server should reply immediately to this
* message, to avoid a timeout disconnect.
*/
bool replyRequested;
} StandbyReplyMessage;
/*
* Hot Standby feedback from standby (message type 'h'). This is wrapped within
* a CopyData message at the FE/BE protocol level.
*
* Note that the data length is not specified here.
*/
typedef struct
{
/*
* The current xmin and epoch from the standby, for Hot Standby feedback.
* This may be invalid if the standby-side does not support feedback, or
* Hot Standby is not yet available.
*/
TransactionId xmin;
uint32 epoch;
/* Sender's system clock at the time of transmission */
TimestampTz sendTime;
} StandbyHSFeedbackMessage;
/*
* Maximum data payload in a WAL data message. Must be >= XLOG_BLCKSZ.
*
* We don't have a good idea of what a good value would be; there's some
* overhead per message in both walsender and walreceiver, but on the other
* hand sending large batches makes walsender less responsive to signals
* because signals are checked only between messages. 128kB (with
* default 8k blocks) seems like a reasonable guess for now.
*/
#define MAX_SEND_SIZE (XLOG_BLCKSZ * 16)
#endif /* _WALPROTOCOL_H */

13
src/include/utils/timestamp.h
View File

@@ -206,13 +206,24 @@ extern Datum generate_series_timestamptz(PG_FUNCTION_ARGS);
/* Internal routines (not fmgr-callable) */
extern TimestampTz GetCurrentTimestamp(void);
extern void TimestampDifference(TimestampTz start_time, TimestampTz stop_time,
long *secs, int *microsecs);
extern bool TimestampDifferenceExceeds(TimestampTz start_time,
TimestampTz stop_time,
int msec);
/*
* Prototypes for functions to deal with integer timestamps, when the native
* format is float timestamps.
*/
#ifndef HAVE_INT64_TIMESTAMP
extern int64 GetCurrentIntegerTimestamp(void);
extern TimestampTz IntegerTimestampToTimestampTz(int64 timestamp);
#else
#define GetCurrentIntegerTimestamp() GetCurrentTimestamp()
#define IntegerTimestampToTimestampTz(timestamp) (timestamp)
#endif
extern TimestampTz time_t_to_timestamptz(pg_time_t tm);
extern pg_time_t timestamptz_to_time_t(TimestampTz t);