Re: beta testing version

> 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