Excellent news. I picked up your patch but have not be able to devote
a large amount of time to it. I'll send you a patch based on the cvs
tip as well as some pointers to proposed changes. I'll contact you
offlist about various workload proposals.
Cheers,
Patrick
J.R. Nield wrote:
I just want to
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
>
> > Yeah, it's a different method of producing a similar outcome. However, many
> > companies do not want to be concerned with the management (and space)
> > of archived logs. Incremental backup allows them the
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
> > Bruce Momjian wrote:
> > >
> > > Someone at Red Hat is working on point-in-time recovery, also known as
> > > incremental backups.
> >
> > PITR and incremental backup are different beasts.
Bruce Momjian wrote:
>
> Someone at Red Hat is working on point-in-time recovery, also known as
> incremental backups.
PITR and incremental backup are different beasts. PITR deals with a backup
+ logs. Incremental backup deals with a full backup + X smaller/incremental
backups.
So... it doesn
Patrick Macdonald wrote:
>
> Tom Lane wrote:
> >
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote:
> > >> Actually, if you don't mind grabbing a copy of pg_filedump --- see
> > &g
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
> > Bruce Momjian wrote:
> > >
> > > I wanted to outline some of the big items we are looking at for 7.4:
> > >
> > > [snip]
> > >
> > > Point-In-Time Recovery (PITR)
> > &
_filedump
> that understands both the 7.2 and 7.3 page layouts (the version field in
> the page header would work for telling what you're looking at)
Correct. The tool will be updated to understand the different
page layouts/formats. Two tools would be a pain...
Cheers,
Patrick
Bruce Momjian wrote:
>
> I wanted to outline some of the big items we are looking at for 7.4:
>
> [snip]
>
> Point-In-Time Recovery (PITR)
>
> J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> MacDonald from Red Hat is working
Zeugswetter Andreas SB SD wrote:
>
> > As noted, one of the main problems is knowing where to begin
> > in the log. This can be handled by having backup processing
> > update the control file with the first lsn and log file
> > required. At the time of the backup, this information is or
> > can
stamp
encountered.
. forward recover stop
Stop the current forward recovery session. Undo all in-flight
transactions and bring the databases down in a consistent
state. No other external user actions should be required.
Looking forward to reading draft 2.
Cheers,
Patrick
--
Patrick Macd
-
Patrick Macdonald
Red Hat Database
Tom Lane wrote:
>
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > Chapter 7 of the Developers guide in about the Page Format on disk and it's
> > a little out of date not to mention somewhat incomplete.
>
&
Tom,
What you are describing is a pseudo circular log. Other database
systems (such as DB2) support the concept of both circular and
recoverable logs. Recoverable is named this way because
recoverable logs can be used in point-in-time recovery. Both
methods support crash recovery.
In genera
Tom Lane wrote:
>
> Patrick Macdonald <[EMAIL PROTECTED]> writes:
> > I understand your solution is for the existing architecture which does
> > not support point-in-time recovery. If this item is picked up, your
> > solution will become a stumbling block due the
Bruce Momjian wrote:
>
> > > > Yes, but in a very roundabout way (or so it seems). The main point
> > > > that I was trying to illustrate was that if a database supports
> > > > point-in-time recovery, recycling of the only available log segments
> > > > is a bad thing. And, yes, in practice if
Bruce Momjian wrote:
>
> > Hmmm... my prior appends to this newsgroup are stalled. Hopefully,
> > they'll be available soon.
> >
> > Tom Lane wrote:
> > >
> > > What you may really be saying is that the existing scheme for management
> > > of log segments is inappropriate for PIT usage; if so fe
Hmmm... my prior appends to this newsgroup are stalled. Hopefully,
they'll be available soon.
Tom Lane wrote:
>
> What you may really be saying is that the existing scheme for management
> of log segments is inappropriate for PIT usage; if so feel free to
> propose a better one. But I don't se
16 matches
Mail list logo
