PostgreSQL 9.0beta1 Documentation | ||||
---|---|---|---|---|
Prev | Fast Backward | Chapter 46. Frontend/Backend Protocol | Fast Forward | Next |
To initiate streaming replication, the frontend sends the "replication" parameter in the startup message. This tells the backend to go into walsender mode, where a small set of replication commands can be issued instead of SQL statements. Only the simple query protocol can be used in walsender mode. The commands accepted in walsender mode are:
Requests the server to identify itself. Server replies with a result set of a single row, and two fields: systemid: The unique system identifier identifying the cluster. This can be used to check that the base backup used to initialize the slave came from the same cluster. timeline: Current TimelineID. Also used to check that the slave is consistent with the master.
Instructs backend to start streaming WAL, starting at point XXX/XXX. Server can reply with an error e.g if the requested piece of WAL has already been recycled. On success, server responds with a CopyOutResponse message, and backend starts to stream WAL as CopyData messages. The payload in CopyData message consists of the following format.
Identifies the message as WAL data.
The log file number of the LSN, indicating the starting point of the WAL in the message.
The byte offset of the LSN, indicating the starting point of the WAL in the message.
Data that forms part of WAL data stream.
A single WAL record is never split across two CopyData messages. When a WAL record crosses a WAL page boundary, however, and is therefore already split using continuation records, it can be split at the page boundary. In other words, the first main WAL record and its continuation records can be split across different CopyData messages.