> As for replaying logs against a restored snapshot dump... AIUI, a
> dump records tuples by OID, but the WAL refers to TIDs. Therefore,
> the WAL won't work as a re-do log to recover your transactions
> because the TIDs of the restored tables are all different.
True for current way of backing up - ie saving data in "external"
(sql) format. But there is another way - saving data files in their
natural (binary) format. WAL records may be applyed to
such dump, right?
> To get replaying we need an "update log", something that might be
What did you mean by "update log"?
Are you sure that WAL is not "update log" ? -:)
> in 7.2 if somebody does a lot of work.
>
> > Note I'm not saying you're wrong, just asking that you explain your
> > comment a little more. If WAL can't be used to help recover from
> > crashes where database corruption occurs, what good is it?
>
> The WAL is a performance optimization for the current recovery
> capabilities, which assume uncorrupted table files. It protects
> against those database server crashes that happen not to corrupt
> the table files (i.e. most). It doesn't protect against corruption
> of the tables, by bugs in PG or in the OS or from "hardware events".
> It also doesn't protect against OS crashes that result in
> write-buffered sectors not having been written before the crash.
> Practically, this means that WAL file entries older than a few
> seconds are not useful for much.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Even now, without BAR, WAL entries become unuseful only after checkpoints
(and I wouldn't recomend to create them each few seconds -:)). WAL based
BAR will require archiving of log records.
Vadim
