Re: AW: Backup, restore & pg_dump - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject Re: AW: Backup, restore & pg_dump
Date
Msg-id 8F4C99C66D04D4118F580090272A7A23018D58@SECTORBASE1
Whole thread Raw
In response to AW: Backup, restore & pg_dump  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
>> Just to clarify; I have no intention of doing anything nasty to pg_dump.

Oh, ok, it wasn't clear, sorry -:)

>>All I plan to do is rename the pg_restore to one of
>>pg_load/pg_import/pg_undump/pmud_gp, to make way for a WAL based
>>restore utility, although as Bruce suggests, this may be premature.
>
>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?
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?

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.

Vadim



pgsql-hackers by date:

Previous
From: Andrew McMillan
Date:
Subject: Re: Full text indexing (Question/request)
Next
From: "Mikheev, Vadim"
Date:
Subject: Ответ: [HACKERS] ????: [HACKERS] Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)