Re: Bug #789: Transaction Archival Logging -- Hot Backups

We will have point-in-time recovery in 7.4. We are just releaseing
7.3beta now.

---------------------------------------------------------------------------

Jon Watte wrote:
>
> Again, thank you for your reply. I am copying the bugs list in the
> hope that some ray of insight will hit.
>
> I looked at this a little more, and it seems pg_dump does not actually
> do what I need. If the database goes down and I lose my main data store,
> then I will lose all transactions back to the time I did the pg_dump.
>
> Other databases (i e Oracle) solves this by retaining their transaction
> journal for some predetermined time (at least as long as the interval
> between data store backups). Typically, you will put this journal on
> some physically separate storage with a physically separate controller
> (maybe even on tape, or on a remote site). Then, when you lose your
> data store, you can restore the data store from back-up, and then re-
> play your archive log, and avoid losing any committed transactions. If
> you lose your archive log store, the database is still intact, and you
> should immediately failover to a new archive store and start a full
> data store backup. If you lose both, then you HAVE to accept the fact
> that you will lose previously committed transactions, but the likelihood
> of this actually happening with the right physical set-up is very very
> slim (as opposed to the likelihood of just one part going down, which
> is almost inevitable).
>
> For reference, this one lacking feature is preventing the company I work
> at from using PostgreSQL, because we have operational requirements that
> need this "fast path" recovery in the common case. Unfortunately, we'd
> rather pay Oracle lots of money than lose time having to implement it in
> the PostgreSQL code :-(
>
> Cheers,
>
> / h+
>
>
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
> > Sent: Saturday, September 28, 2002 10:19 PM
> > To: postgres(dot)org(dot)nospam(at)mindcontrol(dot)org; pgsql-bugs(at)postgresql(dot)org
> > Subject: Re: [BUGS] Bug #789: Transaction Archival Logging -- Hot
> > Backups
> >
> >
> >
> > I see in the pg_dump manual page:
> >
> > pg_dump makes consistent backups even if the database is
> > being used concurrently. pg_dump does not block other
> > users accessing the database (readers or writers).
> >
> >
> > ------------------------------------------------------------------
> > ---------
> >
> > pgsql-bugs(at)postgresql(dot)org wrote:
> > > Jon Watte (postgres(dot)org(dot)nospam(at)mindcontrol(dot)org) reports a bug
> > > with a severity of 2 The lower the number the more severe it
> > > is.
> > >
> > > Short Description Transaction Archival Logging -- Hot Backups
> > >
> > > Long Description I see no mention of transaction archival logging
> > > in the documentation.
> > >
> > > This means that, even though you support correct transaction
> > > rollback semantics, to back up the database in a consistent
> > > manner, I have to take it offline and backup all the files.
> > >
> > > Either I'm missing something (and I did a documentation, FAQ
> > > and Todo search) or it's not currently possibly to actually put
> > > Postgres into a 24/7 production environment?
> > >
> > > Sample Code
> > >
> > >
> > > No file was uploaded with this report
> > >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 2: you can get off all lists at once with the unregister
> > > command
> > > (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> > >
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup. | Newtown Square,
> > Pennsylvania 19073
> >
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073