Re: pgsql: Follow TLI of last replayed record, not recovery target TLI, in

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pgsql: Follow TLI of last replayed record, not recovery target TLI, in
Дата
Msg-id CAHGQGwE9LRNpZxo6m6Hfkc4Nyaw7p5xCRhsx7uKWvjdxSSkaTQ@mail.gmail.com
обсуждение исходный текст
Ответ на pgsql: Follow TLI of last replayed record, not recovery target TLI, in  (Heikki Linnakangas <heikki.linnakangas@iki.fi>)
Список pgsql-committers
On Thu, Dec 20, 2012 at 9:41 PM, Heikki Linnakangas
<heikki.linnakangas@iki.fi> wrote:
> Follow TLI of last replayed record, not recovery target TLI, in walsenders.
>
> Most of the time, the last replayed record comes from the recovery target
> timeline, but there is a corner case where it makes a difference. When
> the startup process scans for a new timeline, and decides to change recovery
> target timeline, there is a window where the recovery target TLI has already
> been bumped, but there are no WAL segments from the new timeline in pg_xlog
> yet. For example, if we have just replayed up to point 0/30002D8, on
> timeline 1, there is a WAL file called 000000010000000000000003 in pg_xlog
> that contains the WAL up to that point. When recovery switches recovery
> target timeline to 2, a walsender can immediately try to read WAL from
> 0/30002D8, from timeline 2, so it will try to open WAL file
> 000000020000000000000003. However, that doesn't exist yet - the startup
> process hasn't copied that file from the archive yet nor has the walreceiver
> streamed it yet, so walsender fails with error "requested WAL segment
> 000000020000000000000003 has already been removed". That's harmless, in that
> the standby will try to reconnect later and by that time the segment is
> already created, but error messages that should be ignored are not good.
>
> To fix that, have walsender track the TLI of the last replayed record,
> instead of the recovery target timeline. That way walsender will not try to
> read anything from timeline 2, until the WAL segment has been created and at
> least one record has been replayed from it. The recovery target timeline is
> now xlog.c's internal affair, it doesn't need to be exposed in shared memory
> anymore.
>
> This fixes the error reported by Thom Brown. depesz the same error message,
> but I'm not sure if this fixes his scenario.

You seem to have forgotten to remove the following line from xlog.h.

src/include/access/xlog.h:312:extern TimeLineID GetRecoveryTargetTLI(void);

Regards,

--
Fujii Masao


В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Fix pg_extension_config_dump() to handle update cases more sanel
Следующее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: Fix grammatical mistake in error message