Re: pg_xlogfile_name_offset() et al and recovery

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: pg_xlogfile_name_offset() et al and recovery
Дата
Msg-id 3649f1e4-ac74-841e-6ae5-cfe0022aa50b@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: pg_xlogfile_name_offset() et al and recovery  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: pg_xlogfile_name_offset() et al and recovery  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On 2016/07/07 16:26, Michael Paquier wrote:
> On Thu, Jul 7, 2016 at 3:59 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> While reading the thread "BUG #14230: Wrong timeline returned by
>> pg_stop_backup on a standby", I came to know that ThisTimelineId is
>> invalid on standby.  And because pg_xlogfile_name_offset() uses the same
>> to compute its result, it makes sense to prevent it from being used on a
>> standby.
> 
> To be honest, I have always found that this restriction was hard to
> justify on a function that basically performs a static calculation. So
> what about removing this error and use GetXLogReplayRecPtr() to fetch
> the timeline ID? Per se the patch attached:
> =# select * from pg_xlogfile_name_offset(pg_last_xlog_replay_location());
>         file_name         | file_offset
> --------------------------+-------------
>  000000010000000000000003 |        2192
> (1 row)
> 
> The same applies of course to pg_xlogfile_name():
> =# select pg_xlogfile_name(pg_last_xlog_replay_location());
>      pg_xlogfile_name
> --------------------------
>  000000010000000000000003
> (1 row)

+1 to enabling these functions' usage on standby and the patch.

Thanks,
Amit





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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Header and comments describing routines in incorrect shape in visibilitymap.c
Следующее
От: Fujii Masao
Дата:
Сообщение: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.