On Thu, Dec 20, 2012 at 8:41 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 20.12.2012 12:08, Amit Kapila wrote:
>>
>> On Wednesday, December 19, 2012 9:30 PM Heikki Linnakangas wrote:
>>>
>>> In both checkpointer.c and bgwriter.c, we do this before entering the
>>> main loop:
>>>
>>> /*
>>> * Use the recovery target timeline ID during recovery
>>> */
>>> if (RecoveryInProgress())
>>> ThisTimeLineID = GetRecoveryTargetTLI();
>>>
>>> That seems reasonable. However, since it's only done once, when the
>>> process starts up, ThisTimeLineID is never updated in those processes,
>>> even though the startup process changes recovery target timeline.
>>>
>>> That actually seems harmless to me, and I also haven't heard of any
>>> complaints of misbehavior in 9.1 or 9.2 caused by that. I'm not sure
>>> why
>>> we bother to set ThisTimeLineID in those processes in the first place.
>>
>>
>> This is used in RemoveOldXlogFiles(), so if during recovery when it's not
>> set and
>> this function gets called, it might have some problem.
>> I think it could get called from CreateRestartPoint() during recovery.
>
>
> Hmm, right, it's used for this:
>
> XLogFileName(lastoff, ThisTimeLineID, segno);
>
> The resulting lastoff string, which is a xlog filename like
> "000000020000000000000008", is used to compare filenames of files in
> pg_xlog. However, the tli part, first 8 characters, are ignored for
> comparison purposes. In addition to that, 'lastoff' is printed in a DEBUG2
> line, purely for debugging purposes.
InstallXLogFileSegment() also uses ThisTimeLineID. But your recent commit
doesn't take care of it and prevents the standby from recycling the WAL files
properly. Specifically, the standby recycles the WAL file to wrong name.
Regards,
--
Fujii Masao