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, 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()
Usage would then be pg_xlogfile_name_offset_timeline(
my_choice_of_timeline(), '3/FF020000')
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
