AW: AW: Backup, restore & pg_dump

> >It is not premature. We will need a WAL based restore for 7.1
> >or we imho don't need to enable WAL for 7.1 at all.
>
> I missed your point here - why ?!
> New backup/restore is not only result of WAL.
> What about recovery & performance?

Ok, recovery is only improved for indexes, no ?
Performance must imho be worse in your first round
(at least compared to -F mode).
There is room for improvement that was not there
before WAL (like avoiding write calls, non-overwrite ...)
but those are not implemented yet.
Please correct me if I am wrong here, but imho we accept that
slowdown, because we gain so much.

> Hm, WAL is required for distributed transactions
> and we are not going to have them in 7.1 - does it
> also mean that we don't need to enable WAL in 7.1?

No, but rollforward is currently the main feature, no ?
Does it make sense to ship WAL without using it's currently
main feature ?

>
> There is WAL - general mechanism for transaction
> recovery & performance, alternative (with regard to
> non-overwriting storage manager) approach to transaction
> systems. And there are WAL based features. Sooner
> we'll get base sooner we'll have features.

Ok, you have implemented startup rollforward anyway.
I think that the logic for a rollforward that starts with a restored tar
backup (if done correctly) will be exactly or at least nearly the same.

That is:
Walk the log, see if the entry is already done, do it if not, else
go to next entry in log.

It could be the responsibility of the dba to decide with which log to begin
rollforward after restore.

Andreas