Re: pg_xlogfile_name_offset() et al and recovery

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_xlogfile_name_offset() et al and recovery
Date: 2016-07-07 07:26:14
Message-ID: CAB7nPqTR8kZ=whdSy+k7Q5oJRAPDAfTt7LqHn-sLD3eAZZc2Rg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)
--
Michael

Attachment Content-Type Size
xlogfuncs-tli-recovery.patch text/x-patch 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

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