aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2012-12-20 22:00:34 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2012-12-20 22:00:58 +0200
commit343ee00b730e9c422082160718b9785f0cb7f8f6 (patch)
tree88211e1c4d94b7fc293b41ba9220f656311d4bd3 /src/backend/access/gist/gistget.c
parentdc9896a2457f0d72458f1ff45935362521f0f99c (diff)
downloadpostgresql-343ee00b730e9c422082160718b9785f0cb7f8f6.tar.gz
postgresql-343ee00b730e9c422082160718b9785f0cb7f8f6.zip
Fix recycling of WAL segments after switching timeline during recovery.
This was broken before, we would recycle old WAL segments on wrong timeline after the recovery target timeline had changed, but my recent commit to not initialize ThisTimeLineID at all in a standby's checkpointer process broke this completely. The problem is that when installing a recycled WAL segment as a future one, ThisTimeLineID is used to construct the filename. To fix, always update ThisTimeLineID to the current timeline being recovered, before recycling WAL segments at a restartpoint. This still leaves a small window where we might install WAL segments under wrong timeline ID, if the timeline is changed just as we're about to start recycling. Also, even if we're replaying timeline X at the momnent, there's no guarantee that we'll need as many WAL segments on that timeline as we recycle. We might be just about to reach the point where we switch to next timeline, so might only need one more WAL segment on the current timeline. We'll live with the waste in that situation. Bug pointed out by Fujii Masao. 9.1 and 9.2 had the same issue, when recovery target timeline was changed, but I committed a slightly different version of this patch on those branches.
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions