Re: ThisTimeLineID in checkpointer and bgwriter processes

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: 'PostgreSQL-development' <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: ThisTimeLineID in checkpointer and bgwriter processes
Date: 2012-12-20 11:41:51
Message-ID: 50D2F97F.4020102@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

So I think we're good on that front. But I'll add a comment there, and
use 0 explicitly instead of ThisTimeLineID, for clarity.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-12-20 11:49:54 Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
Previous Message Groshev Andrey 2012-12-20 11:41:37 Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1