Re: PITR (was Re: Type of application that use - Mailing list pgsql-general

From Shridhar Daithankar
Subject Re: PITR (was Re: Type of application that use
Date
Msg-id 3F8170A3.4040902@persistent.co.in
Whole thread Raw
In response to Re: PITR (was Re: Type of application that use  (Ron Johnson <ron.l.johnson@cox.net>)
List 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 by date:

Previous
From: Shridhar Daithankar
Date:
Subject: Re: Server recommendations
Next
From: Harald Fuchs
Date:
Subject: Re: migrate from postgres to mysql