Re: Failing start-up archive recovery at Standby mode in PG9.2.4

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Kyotaro HORIGUCHI <kyota(dot)horiguchi(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, Andres Freund <andres(at)2ndquadrant(dot)com>
Subject: Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Date: 2013-04-26 07:09:44
Message-ID: 517A2838.5090105@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26.04.2013 07:02, Kyotaro HORIGUCHI wrote:
> I am uncertain a bit weather it is necessary to move curFileTLI to
> anywhere randomly read . On a short glance, the random access occurs also
> for reading checkpoint-related records.

I didn't understand that.

> Also I don't have clear distinction between lastSegmentTLI and curFileTLI
> after the patch applied.

In short, lastSegmentTLI is the TLI in first page of the last opened
segment, while curFileTLI is the TLI in the filename of the last opened
segment. Usually they're the same, but in a segment that contains a
timeline switch, they differ. For example, if you perform PITR to a
point in the middle of segment 000000010000000000000062, you end up with
two segments:

000000010000000000000062
000000020000000000000062

The first half of those files are identical, but the latter contains a
time-line changing checkpoint record in the middle, and from that point
on the contents are different. When we open file
000000020000000000000062, lastSegmentTLI is 1, because the first half of
that segment contains WAL from timeline 1, but curFileTLI is 2, because
that's the TLI in the filename.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-04-26 07:39:35 Re: event trigger API documentation?
Previous Message Daniel Farina 2013-04-26 06:53:24 Re: pg_controldata gobbledygook