Re: Issues Outstanding for Point In Time Recovery (PITR)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Issues Outstanding for Point In Time Recovery (PITR)
Дата
Msg-id 200207170525.g6H5PsI29105@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Issues Outstanding for Point In Time Recovery (PITR)  ("J. R. Nield" <jrnield@usol.com>)
Ответы Re: Issues Outstanding for Point In Time Recovery (PITR)  ("J. R. Nield" <jrnield@usol.com>)
Список pgsql-hackers
J. R. Nield wrote:
> On Tue, 2002-07-16 at 15:36, Bruce Momjian wrote:
> > 
> > J.R., just checking to see how PITR recovery is going.  Do you need any
> > assistance or have any questions for us?
> > 
> > Also, do you have any idea how close you are to having something
> > completed?  Are you aware we are closing development of 7.3 at the end
> > of August and start beta September 1?  Is there any way we can help you?
> > 
> 
> It should be ready to go into CVS by the end of the month. 
> 
> That will include: logging all operations except for rtree and GiST,
> archival of logfiles (with new postgresql.conf params), headers on the
> logfiles to verify the system that created them, standalone backend
> recovery to a point-in-time, and a rudimentary hot backup capability.

Sounds great.  That gives us another month to iron out any remaining
issues.  This will be a great 7.3 feature!


> I could use some advice on the proper way to add tests to configure.in,
> given that the autoconf output is in CVS. Would you ever want a patch to
> include the generated 'configure' file?

We only patch configure.in.  If you post to hackers, they can give you
assistance and I will try to help however I can.  I can so some
configure.in stuff for you myself.

> Related to that, the other place I need advice is on adding Ted Tso's
> LGPL'd UUID library (stolen from e2fsprogs) to the source. Are we
> allowed to use this? There is a free OSF/DCE spec for UUID's, so I can
> re-implement the library if required.

We talked about this on the replication mailing list.  We decided that
hostname, properly hashed to an integer, was the proper way to get this
value.  Also, there should be a postgresql.conf variable so you can
override the hostname-generated value if you wish.  I think that is
sufficient.

> We also haven't discussed commands for backup/restore, but I will use
> what I think is appropriate and we can change the grammar if needed. The
> initial hot-backup capability will require the database to be in
> read-only mode and use tar for backup, and I will add the ability to
> allow writes later.

Yea, I saw Tom balked at that. I think we have enough manpower and time
that we can get hot backup in normal read/write mode working before 7.3
beta so I would just code it assuming the system is live and we can deal
with making it hot-capable once it is in CVS.  It doesn't have to work
100% until beta time.

> Does this sound like a reasonable timeframe/feature-set to make the 7.3
> release?

Sounds great.  This is another killer 7.3 feature, and we really need
this for greater enterprise acceptance of PostgreSQL.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: DROP COLUMN
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Do we still need these NOTICEs?