From: | Gerhard Wiesinger <lists(at)wiesinger(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Richard Huxton <dev(at)archonet(dot)com> |
Subject: | Re: Problems with postgres online backup - restore |
Date: | 2009-06-26 04:28:33 |
Message-ID: | alpine.LFD.2.00.0906260624460.24444@bbs.intern |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
OK, what's then the difference doing a pg_start_backup() or just
doing the backup?
Isn't that a problem that the datablock are very inconsistent, even so
inconsistent that they are corrupt:
E.g. A part of a datablock is written when e.g. the file is tarred. =>
Datablock on backup is corrupt => An then even the WAL can't be applied.
Why does it work correctly? Or is there some design problem?
Thnx.
Ciao,
Gerhard
On Thu, 25 Jun 2009, Richard Huxton wrote:
> Gerhard Wiesinger wrote:
>> Hello,
>>
>> I'd like to understand the PostgreSQL internals in "backup mode".
>>
>> When I understood it correctly pg_start_backup() make a checkpoint and
>> stops writing to the data/ directory except the WAL.
>>
>> All new transaction go into WAL which is also logical. But how is data
>> consistency done when the written/changed blocks don't fit into the buffer
>> cache?
>
> The data isn't kept consistent. Which is why you need the WAL. Restoring from
> a PITR backup is basically the same idea as recovering from a crash. Any
> blocks that might have been updated since you called pg_start_backup() will
> be rewritten from the WAL.
>
> --
> Richard Huxton
> Archonet Ltd
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | CM J | 2009-06-26 05:07:19 | Re: [JDBC] Postgres 8.3.7 -- EOF on client connection |
Previous Message | Tom Lane | 2009-06-26 02:53:56 | Re: Custom runtime variables |