Re: Recovery - transaction logs

Поиск
Список
Период
Сортировка
От Naomi Walker
Тема Re: Recovery - transaction logs
Дата
Msg-id 4.2.2.20020206120611.00a71da0@ecint.ecinet.com
обсуждение исходный текст
Ответ на Re: Recovery - transaction logs  ("Andy Marden" <amarden@usa.net>)
Список 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 по дате отправления:

Предыдущее
От: Manav
Дата:
Сообщение: pg_dump version
Следующее
От: Phill Kenoyer
Дата:
Сообщение: Re: Persistent Connections with PHP and PostgreSQL