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
|
Список | 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 по дате отправления: