Re: PITR (was Re: Type of application that use

Поиск
Список
Период
Сортировка
От Shridhar Daithankar
Тема Re: PITR (was Re: Type of application that use
Дата
Msg-id 3F8170A3.4040902@persistent.co.in
обсуждение исходный текст
Ответ на Re: PITR (was Re: Type of application that use  (Ron Johnson <ron.l.johnson@cox.net>)
Список pgsql-general
Ron Johnson wrote:

> On Mon, 2003-10-06 at 01:47, Shridhar Daithankar wrote:
>
>>Ron Johnson wrote:
>>>Hope everybody realizes that the amount of WALs will get very big
>>>on active-update systems...
>>Of course they will be recycled in some point of time or other. And even if
> ????  Of course they'll get recycled, after you dump them, prior
> to the nightly pg_dump.

The WAL under PITR will not swell till it fills the partition. In all
probability there will be(should be) a parameter to control how much space it
can occupy at the most. Otherwise it simply does not make sense.

>>postgresql would provide PITR abilities, that would be nearly useless if WAL is
>>recycled.. Its a space/time tradeoff issue..
> Again, ?????.  Typically (i.e., on DBMSs that currently have PITR,
> it's possible to do a "pg_dump" on Sunday, and *only* do "WAL dumps"
> each subsequent night, and be able to restore the DB to the point
> of failure by doing a "pg_restore" and then applying X number of
> "WAL dumps" in sequence.

Yes. But when PITR realises, there will be/should be a command/switch to pg_dump
to back up a WAL segment, so that the particular WAL segment could be recycled.

No matter what, WAL remains a resource that should be used sparingly.

PITR is not yet visible as yet. When the discussion starts for providing front
end to PITR, such facilities are going to be suggested and are essential IMO..

Just a thought..

  Shridhar


В списке pgsql-general по дате отправления:

Предыдущее
От: Shridhar Daithankar
Дата:
Сообщение: Re: Server recommendations
Следующее
От: Harald Fuchs
Дата:
Сообщение: Re: migrate from postgres to mysql