Re: Recovery - transaction logs - Mailing list pgsql-admin

From Naomi Walker
Subject Re: Recovery - transaction logs
Date
Msg-id 4.2.2.20020206120611.00a71da0@ecint.ecinet.com
Whole thread Raw
In response to Re: Recovery - transaction logs  ("Andy Marden" <amarden@usa.net>)
List pgsql-admin
Actually, we do consider this to be a problem. From what I am hearing, they
are close to having some sort of point in time recovery.

An option to consider, i'm quite sure if we threw some money the developers
way, they might be persuaded.



At 10:46 AM 2/6/02 +0000, Andy Marden wrote:
>Does no one consider this to be a problem? You kinda wonder about PostgreSQL
>being used as serious commercial database then don't you?
>
>Me again.
>
>"Andy Marden" <amarden@usa.net> wrote in message
>news:a3dpjt$1l1s$1@news.tht.net...
> > Putting together a system at the moment with a combination of batch loads
> > and user online modification of data, with PostgreSQL version 7.1.3. I'm
> > looking at recovery aspects at the moment. All I can see is pg_dump and
> > pg_restore at the moment, which is fine for batch loads once a day, but if
> > the database crashes halfway through the day then user modifications will
>be
> > lost.
> >
> > Is there the equivalent of Oracle's archived redo logs in PostgreSQL and
> > commands to allow recovery up to the last (or any) point in time. I've
>seen
> > pg_xlog files mentioned.
> >
> > The recovery section of the manuals is 'under construction' it seems.
> >
> > Thanks for your help.
> >
> > Cheers
> >
> > Andy Marden
> >
> >
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html

--
Naomi Walker
Chief Information Officer
Eldorado Computing, Inc.
602-604-3100  ext 242


pgsql-admin by date:

Previous
From: Manav
Date:
Subject: pg_dump version
Next
From: Phill Kenoyer
Date:
Subject: Re: Persistent Connections with PHP and PostgreSQL