Re: Fast promotion failure

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