Re: .ready and .done files considered harmful

At Thu, 5 Aug 2021 21:53:30 +0530, Dipesh Pandit <dipesh(dot)pandit(at)gmail(dot)com> wrote in
> > I'm not sure. I think we need the value to be accurate during
> > recovery, so I'm not sure whether replayEndTLI would get us there.
> > Another approach might be to set ThisTimeLineID on standbys also.
> > Actually just taking a fast look at the code I'm not quite sure why
> > that isn't happening already. Do you have any understanding of that?
>
> During investigation I found that the current timeline ID (ThisTimeLineID)
> gets updated in XLogCtl’s ThisTimeLineID once it gets finalised as part
> of archive recovery.
>
> /*
> * Write the timeline history file, and have it archived. After this
> * point (or rather, as soon as the file is archived), the timeline
> * will appear as "taken" in the WAL archive and to any standby
> * servers. If we crash before actually switching to the new
> * timeline, standby servers will nevertheless think that we
> switched
> * to the new timeline, and will try to connect to the new timeline.
> * To minimize the window for that, try to do as little as possible
> * between here and writing the end-of-recovery record.
> */
>
> In case of Standby this happens only when it gets promoted.
>
> If Standby is in recovery mode then replayEndTLI points to the most
> recent TLI corresponding to the replayed records. Also, if replying a
> record causes timeline switch then replayEndTLI gets updated with
> the new timeline. As long as it is in recovery mode replayEndTLI should
> point to the current timeline ID on Standby. Thoughts?

As I mentioned in another branch of this thread, pgarch_readyXlog()
always goes into the fall back path at the first iteration of
pgarch_ArchiverCopyLoop() and the current (or expected) TLI is
informed there. So no need of shared timeline ID at that time.

When pgarch_ArchiverCopyLoop meets a timeline switch, the short cut
path fails to find the next anticipated .ready file then goes into the
fallback path, which should find the history file for the next TLI
(unless any timing misalignment I'm not aware of happens).

So the shared timeline id works only to let the fast path give way to
the fall back path to find the just created history file as earlier as
possible. Notifying the timeline ID that the startup process
recognizes to archiver makes thing more complex than requied.
Currently archiver doesn't use SIGINT, so I think we can use sigint
for the purpose.

Furthermore, it seems to me that we can make the TLI and the next
anticipated segment number function-local static variables. It would
be workable assuming that the only caller pgarch_ArchiverCopyLoop
obeys the contract that it must call pgarch_readyXlog() until it
returns false. However, there seems to be no reason for it not to
work even otherwise, unless I'm missing something (that's likely),
though.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center