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
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 |