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

From: Kyotaro HORIGUCHI <kyota(dot)horiguchi(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(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 04:02:03
Message-ID: CAM103Du2gcK1xJCC4OXtpO44X2bCBhX11=GUr_nSO1RyxA-4hA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you for the patch.

The test script finishes in success with that. And looks reasonable on a
short glance.

On Fri, Apr 26, 2013 at 4:34 AM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
wrote:
> One idea to fix this is to not set curFileTLI, until the page header on
the
> just-opened file has been verified. Another idea is to change the check in
> XLogFileReadAnyTLI() that currently forbids curFileTLI from moving
> backwards. We could allow curFileTLI to move backwards, as long as the
> tli is >= ThisTimeLineID (ThisTimeLineID is the current timeline we're
> recovering records from).
>
> Attached is a patch for the 2nd approach. With the patch, the test script
> works for me. Thoughts?

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.
Also I don't have clear distinction between lastSegmentTLI and curFileTLI
after the patch applied. Although , I need look closer around them to
understand.

> PS. This wasn't caused by the 9.2.4 change to do crash recovery before
> entering archive recovery. The test script fails in the same way with
9.2.3
> as well.

--
Kyotaro Horiguchi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-04-26 04:21:58 Re: pg_controldata gobbledygook
Previous Message Peter Geoghegan 2013-04-26 03:22:48 Re: pg_controldata gobbledygook