Re: pg_xlogfile_name_offset() et al and recovery
От | Michael Paquier |
---|---|
Тема | Re: pg_xlogfile_name_offset() et al and recovery |
Дата | |
Msg-id | CAB7nPqTR8kZ=whdSy+k7Q5oJRAPDAfTt7LqHn-sLD3eAZZc2Rg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_xlogfile_name_offset() et al and recovery (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: pg_xlogfile_name_offset() et al and recovery
Re: pg_xlogfile_name_offset() et al and recovery |
Список | pgsql-hackers |
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) -- Michael
Вложения
В списке pgsql-hackers по дате отправления: