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