Re: pg_xlogfile_name_offset() et al and recovery - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_xlogfile_name_offset() et al and recovery
Date
Msg-id CAB7nPqTR8kZ=whdSy+k7Q5oJRAPDAfTt7LqHn-sLD3eAZZc2Rg@mail.gmail.com
Whole thread Raw
In response to Re: pg_xlogfile_name_offset() et al and recovery  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses 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  (Simon Riggs <simon@2ndquadrant.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Don't include MMAP DSM's transient files in basebackup
Next
From: Noah Misch
Date:
Subject: Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)