Re: pg_xlogfile_name_offset() et al and recovery

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

In response to

Responses

Browse pgsql-hackers by date

  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