Re: Restore postgres to specific time

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)mail(dot)com>
Cc: wd <wd(at)wdicc(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Restore postgres to specific time
Date: 2012-11-28 05:26:46
Message-ID: CAMkU=1wZxTp4JA-VdDqmbqsp1tyThFkMO+DCCxZ+mkBoSjoY1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Nov 27, 2012 at 6:59 AM, Kevin Grittner <kgrittn(at)mail(dot)com> wrote:
> wd wrote:
>
>> the time is between backup start and stop.
>
> That is the problem -- until the point where pg_stop_backup() was
> run PostgreSQL can't be sure of having a consistent database.

In 9.2, it seems to be willing to give it a shot anyway.

It will start up a hot standby as soon as the end-of-checkpoint record
(the one from the pg_start_backup) gets replayed. I'm pretty sure
that this is a bug, but I have not been able to provoke hot standby
into given me wrong answers due to it. I think it is another
manifestation of the same issue I reported to bugs list about commit
8366c7803ec3d059.

Or is this not a bug? It certainly seems like it would be, because
the hot standby can now read data pages that were modified at a time
that is still "in the future" as far as the currently state of replay
is concerned. Those changes will mostly be invisible because the xid
will also be in the future (which is probably why I haven't been able
to force inconsistencies) but it seems like there must be some
situations in which that is not enough to save us.

Cheers,

Jeff

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tobias Meyer 2012-11-28 09:02:56 Determine unused / not referenced large Objects
Previous Message Rodrigo Rosenfeld Rosas 2012-11-28 01:36:52 Re: distinct values and count over window function