On 21.05.2013 00:00, Simon Riggs wrote:
> When we set the new timeline we should be updating all values that
> might be used elsewhere. If we do that, then no matter when or how we
> run GetXLogReplayRecPtr, it can't ever get it wrong in any backend.
>
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -5838,8 +5838,16 @@ StartupXLOG(void)
> }
>
> /* Save the selected TimeLineID in shared memory, too */
> - XLogCtl->ThisTimeLineID = ThisTimeLineID;
> - XLogCtl->PrevTimeLineID = PrevTimeLineID;
> + {
> + /* use volatile pointer to prevent code rearrangement */
> + volatile XLogCtlData *xlogctl = XLogCtl;
> +
> + SpinLockAcquire(&xlogctl->info_lck);
> + XLogCtl->ThisTimeLineID = ThisTimeLineID;
> + XLogCtl->lastReplayedTLI = ThisTimeLineID;
> + XLogCtl->PrevTimeLineID = PrevTimeLineID;
> + SpinLockRelease(&xlogctl->info_lck);
> + }
Hmm. lastReplayedTLI is supposed to be the timeline of the last record
that was replayed, ie. the timeline corresponding lastReplayedEndRecPtr.
I think it would work, but it feels like it could be an easy source of
bugs in the future.
It might be a good idea to change walsender to not store that in
ThisTimeLineID, though. It used to make sense for ThisTimeLineID to
track the current recovery timeline in 9.2 and below, but now that
walsender can be sending any older timeline, using ThisTimeLineID to
store the latest one seems confusing.
- Heikki
