Re: xlog filename formatting functions in recovery

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog filename formatting functions in recovery
Date: 2012-09-25 16:16:06
Message-ID: CAHGQGwGi+q+zK1yh+ZG=v5gsHBBkkvfcqXcJiuB80pX9sp5t-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 25, 2012 at 11:05 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 21 September 2012 02:25, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-09-25 16:29:50 Re: Oid registry
Previous Message Tom Lane 2012-09-25 16:14:29 Re: Oid registry