Re: xlog filename formatting functions in recovery - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: xlog filename formatting functions in recovery
Date
Msg-id CAHGQGwGi+q+zK1yh+ZG=v5gsHBBkkvfcqXcJiuB80pX9sp5t-A@mail.gmail.com
Whole thread Raw
In response to Re: xlog filename formatting functions in recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: xlog filename formatting functions in recovery  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Sep 25, 2012 at 11:05 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 21 September 2012 02:25, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
>> On 03.07.2012 15:13, Robert Haas wrote:
>>>
>>> On the substance of the patch, I believe the reason why this is
>>> currently disallowed is because the TLI is implicitly taken from the
>>> running system, and on the standby that might be the wrong value.
>>
>>
>> Yeah, I believe that's the reason. So the question is, what timeline should
>> the functions use on a standby? With the patch as it is, they use 0:
>>
>> postgres=# select pg_xlogfile_name_offset('3/FF020000');
>>       pg_xlogfile_name_offset
>> -----------------------------------
>>  (0000000000000003000000FF,131072)
>> (1 row)
>>
>> There's a few different options:
>>
>> 1. current recovery_target_timeline (XLogCtl->recoveryTargetTLI)
>> 2. current ThisTimeLineID, which is bumped every time a timeline-bumping
>> checkpoint record is replayed. (this is not currently visible to backends,
>> but we could easily add a shared memory variable for it)
>> 3. curFileTLI. That is, the TLI of the current file that we're replaying.
>> This is usually the same as ThisTimeLineID, except when replaying a WAL
>> segment where the timeline changes
>> 4. Something else?
>>
>> What do you use these functions for? Which option would make the most sense?
>
> I would say there is no sensible solution.
>
> So we keep pg_xlogfile_name_offset() banned in recovery, as it is now.
>
> We introduce pg_xlogfile_name_offset_timeline() where you have to
> manually specify the timeline,

I agree to introduce such function, but what about extending pg_xlogfile_name
and pg_xlogfile_name_offset so that they accept the timeline ID as the second
argument, instead of adding new functions? If the second argument is omitted,
current timeline ID is used to calculate the WAL file name.

> then introduce 3 functions that map
> onto the 3 options above, forcing the user to choose which one they
> mean.
> pg_recovery_target_timeline()
> pg_recovery_current_timeline()
> pg_reocvery_current_file_timeline()

It seems to me that it's not easy for a user to understand the difference
of those functions. Since I think that pg_xlogfile_name is likely to be used
together with pg_last_xlog_receive_location and pg_last_xlog_replay_location
in the standby, it seems better to introduce something like
pg_last_xlog_receive_timeline and pg_last_xlog_replay_timeline. That is,
a user would execute, for example,
   SELECT pg_xlogfile_name(pg_last_xlog_replay_location(),
pg_last_xlog_replay_timeline());

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Oid registry
Next
From: Andrew Dunstan
Date:
Subject: Re: Oid registry