Re: Re: Problem with PITR recovery

From: <simon(at)2ndquadrant(dot)com>
To: Rob Butler <crodster2k(at)yahoo(dot)com>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jeff Davis <jdavis-pgsql(at)empires(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Problem with PITR recovery
Date: 2005-04-18 14:44:02
Message-ID: 28292295$11138352694263c705cad362.62006327@config17.schlund.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Rob Butler <crodster2k(at)yahoo(dot)com> wrote on 18.04.2005, 15:05:20:
>
> > I'd say it's very not cool :) It's not we all
> > expected from PITR.
> > I recall now Simon mentioned about that and have it
> > in his TODO.
> > Other thing I don't understand what's the problem to
> > generate WAL file
> > by demand ? Probably, TODO should says about this.
>
> This would definetly be a good feature to have. What
> I would prefer is:
>
> 1) have the pitr stop command write out and close the
> WAL that it is currently using.
>
> 2) have another stored proc which can be invoked at
> any time that will write out and close the WAL that is
> currently in use when that command is executed.
>
> 3) have a feature in postgres that will automatically
> write out and close the WAL if the server hasn't had
> any activity in XX minutes, or hasn't closed a WAL
> file in XX minutes.

Yes, I have been working on a design.

1) is required to make PITR better for low transaction rate users.

3) is required to allow standby replication

2) is a standard feature on other DBMS, but I'd have to consider that as
optional.

Anyway, I'll post more in a few hours on this.

Best Regards, Simon Riggs

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2005-04-18 14:48:59 Re: Problem with PITR recovery
Previous Message Bruce Momjian 2005-04-18 14:06:33 Re: Problem with PITR recovery