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