aboutsummaryrefslogtreecommitdiff
path: root/src/backend/storage/buffer/bufmgr.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2013-01-17 20:23:00 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2013-01-17 20:23:00 +0200
commit0b6329130e8e4576e97ff763f0e773347e1a88af (patch)
tree7902ba1fa99ac8124232122ce16231cff0b0e21e /src/backend/storage/buffer/bufmgr.c
parent8ae35e91807508872cabd3b0e8db35fc78e194ac (diff)
downloadpostgresql-0b6329130e8e4576e97ff763f0e773347e1a88af.tar.gz
postgresql-0b6329130e8e4576e97ff763f0e773347e1a88af.zip
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.
Diffstat (limited to 'src/backend/storage/buffer/bufmgr.c')
0 files changed, 0 insertions, 0 deletions