Re: .ready and .done files considered harmful - Mailing list pgsql-hackers

From Dipesh Pandit
Subject Re: .ready and .done files considered harmful
Date
Msg-id CAN1g5_GHgJStPa7HgC7LD_3h3cBz64YPQYc6+-tTC0QnoMBk8A@mail.gmail.com
Whole thread Raw
In response to Re: .ready and .done files considered harmful  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: .ready and .done files considered harmful  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
> 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?

Thanks,
Dipesh

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Lowering the ever-growing heap->pd_lower
Next
From: Andrew Dunstan
Date:
Subject: Re: very long record lines in expanded psql output