Re: .ready and .done files considered harmful

Поиск
Список
Период
Сортировка
От Dipesh Pandit
Тема Re: .ready and .done files considered harmful
Дата
Msg-id CAN1g5_GHgJStPa7HgC7LD_3h3cBz64YPQYc6+-tTC0QnoMBk8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: .ready and .done files considered harmful  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: .ready and .done files considered harmful
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Lowering the ever-growing heap->pd_lower
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: very long record lines in expanded psql output