From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_xlogfile_name_offset() et al and recovery |
Date: | 2016-07-07 07:48:57 |
Message-ID: | 3649f1e4-ac74-841e-6ae5-cfe0022aa50b@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2016-07-07 07:49:18 | Re: Don't include MMAP DSM's transient files in basebackup |
Previous Message | Michael Paquier | 2016-07-07 07:48:00 | Re: Header and comments describing routines in incorrect shape in visibilitymap.c |