Alvaro Herrera wrote:
> But a "savepoint" has a very precise meaning in the SQL standard,
> which relates to points in a transaction you can roll back to. I
> don't think you want to overload with this other meaning, which I see
> as putting a special mark in the XLog -- completely unrelated.
The
Simon Riggs wrote:
On Thu, 2004-04-29 at 16:09, Peter Eisentraut wrote:
Perhaps that was the inspiration, but no, I definitely meant a
CHECKPOINT.
But now you come to mention it, it would be better just to have a
command that simply wrote a named record to the xlog, so it can
be searched for lat
On Thu, 2004-04-29 at 16:09, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > I'd suggest extending the CHECKPOINT command so you can say:
> > CHECKPOINT
> > e.g. CHECKPOINT 'starting payroll Feb04';
> > (I'm sure some other DBMS does this...head spinning can;t recall...)
> > the text could just a
On Thu, Apr 29, 2004 at 05:09:19PM +0200, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > I'd suggest extending the CHECKPOINT command so you can say:
> > CHECKPOINT
> > e.g. CHECKPOINT 'starting payroll Feb04';
> > (I'm sure some other DBMS does this...head spinning can;t recall...)
> > the text
Simon Riggs wrote:
> I'd suggest extending the CHECKPOINT command so you can say:
> CHECKPOINT
> e.g. CHECKPOINT 'starting payroll Feb04';
> (I'm sure some other DBMS does this...head spinning can;t recall...)
> the text could just appear in the xlog record data packet...
I believe you are thinki
Simon Riggs said:
> On Wed, 2004-04-28 at 18:35, Andrew Dunstan wrote:
>> Simon Riggs wrote:
>>
>> >On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote:
>> >
>> >
>> >>What if we added transaction id to log_line_prefix? The user could
>> >>then log all queries and find the xid where they want to stop
On Wed, 2004-04-28 at 18:35, Andrew Dunstan wrote:
> Simon Riggs wrote:
>
> >On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote:
> >
> >
> >>What if we added transaction id to log_line_prefix? The user could then
> >>log all queries and find the xid where they want to stop, but of course
> >>that
Simon Riggs wrote:
On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote:
What if we added transaction id to log_line_prefix? The user could then
log all queries and find the xid where they want to stop, but of course
that assumes they have enabled such logging, and they have access to the
logs.
On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Tue, 2004-04-27 at 21:56, Rod Taylor wrote:
> > > > Overall, I'd refer back to the points Bruce raised - you certainly do
> > > > need a way of finding out the time to recover to, and as others have
> > > > said also, tim
Bruno Wolff III wrote:
The context of my suggestion was for recovering up until a transaction which
messed things up was committed. I did not want the problem transaction to
be committed. If the problem transaction ran for a long time, there might
be other transactions that I want to keep, if possi
On Thu, May 27, 2004 at 23:02:42 +,
Peter Galbavy <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III wrote:
> >For long running transactions where you want to recover as much as
> >possible,
> >one might also want to recover up until just before a specific transaction
> >committed (as opposed to s
Simon Riggs wrote:
> On Tue, 2004-04-27 at 21:56, Rod Taylor wrote:
> > > Overall, I'd refer back to the points Bruce raised - you certainly do
> > > need a way of finding out the time to recover to, and as others have
> > > said also, time isn't the only desirable "recovery point".
> >
> > Wouldn
Another idea would be to provide some means to roll a database forwards
and backwards. If you're doing a recovery because you did something like
an accidental UPDATE SET field = blah without a where clause, what you
really care about is going up to the point right before that update. If
there's a l
On Tue, 2004-04-27 at 23:11, Rod Taylor wrote:
> On Tue, 2004-04-27 at 17:36, Simon Riggs wrote:
> > On Tue, 2004-04-27 at 21:56, Rod Taylor wrote:
> > > > Overall, I'd refer back to the points Bruce raised - you certainly do
> > > > need a way of finding out the time to recover to, and as others h
On Fri, 2004-05-28 at 00:02, Peter Galbavy wrote:
> Bruno Wolff III wrote:
> > For long running transactions where you want to recover as much as possible,
> > one might also want to recover up until just before a specific transaction
> > committed (as opposed to started).
>
> If your DB has died
On Tue, 2004-04-27 at 17:36, Simon Riggs wrote:
> On Tue, 2004-04-27 at 21:56, Rod Taylor wrote:
> > > Overall, I'd refer back to the points Bruce raised - you certainly do
> > > need a way of finding out the time to recover to, and as others have
> > > said also, time isn't the only desirable "rec
Bruno Wolff III wrote:
For long running transactions where you want to recover as much as possible,
one might also want to recover up until just before a specific transaction
committed (as opposed to started).
If your DB has died and you are recovering it, how do you reestablish a
session so that
On Tue, 2004-04-27 at 21:56, Rod Taylor wrote:
> > Overall, I'd refer back to the points Bruce raised - you certainly do
> > need a way of finding out the time to recover to, and as others have
> > said also, time isn't the only desirable "recovery point".
>
> Wouldn't it be sufficient to simply u
> Overall, I'd refer back to the points Bruce raised - you certainly do
> need a way of finding out the time to recover to, and as others have
> said also, time isn't the only desirable "recovery point".
Wouldn't it be sufficient to simply use the transaction ID and ensure
that all the parameters
On Tue, 2004-04-27 at 18:43, Bruno Wolff III wrote:
> On Tue, Apr 27, 2004 at 10:38:45 +0100,
> Richard Huxton <[EMAIL PROTECTED]> wrote:
> >
> > Speaking as a DBA, what I usually want to do is restore to "immediately before
> > I started the payroll calculation". An actual wall-clock time is m
On Tue, 2004-04-27 at 08:56, Hans-Jürgen Schönig wrote:
> Simon Riggs wrote:
> > Since Phase1 is functioning and should hopefully soon complete, we can
> > now start thinking about Phase 2: full recovery to a point-in-time.
> >
> > Previous thinking was that a command line switch would be used t
On Tue, 2004-04-27 at 10:38, Richard Huxton wrote:
> On Tuesday 27 April 2004 00:32, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Mon, 2004-04-26 at 23:01, Alvaro Herrera wrote:
> > > > On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote:
> > > > > I was thinking --- how would so
On Tue, Apr 27, 2004 at 10:38:45 +0100,
Richard Huxton <[EMAIL PROTECTED]> wrote:
>
> Speaking as a DBA, what I usually want to do is restore to "immediately before
> I started the payroll calculation". An actual wall-clock time is mostly
> irrelevant to me.
For long running transactions wher
On Tuesday 27 April 2004 00:32, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Mon, 2004-04-26 at 23:01, Alvaro Herrera wrote:
> > > On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote:
> > > > I was thinking --- how would someone know the time to use for
> > > > restore?
> > >
> > > I
Simon Riggs wrote:
Since Phase1 is functioning and should hopefully soon complete, we can
now start thinking about Phase 2: full recovery to a point-in-time.
Previous thinking was that a command line switch would be used to
specify recover to a given point in time, rather than the default, which
wi
Simon Riggs wrote:
> On Mon, 2004-04-26 at 23:01, Alvaro Herrera wrote:
> > On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote:
> > > Simon Riggs wrote:
> > > > Transaction log files currently have timestamps, so that is
> > > > straightforward, but probably not the best we can do. We wo
On Mon, 2004-04-26 at 23:01, Alvaro Herrera wrote:
> On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > Transaction log files currently have timestamps, so that is
> > > straightforward, but probably not the best we can do. We would
> > > rollforward until t
On Mon, 2004-04-26 at 22:05, Bruce Momjian wrote:
> Simon Riggs wrote:
> > Transaction log files currently have timestamps, so that is
> > straightforward, but probably not the best we can do. We would
> > rollforward until the xlog file time > desired point in time.
> >
> > To make (2) work we wo
On Mon, Apr 26, 2004 at 05:05:41PM -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > Transaction log files currently have timestamps, so that is
> > straightforward, but probably not the best we can do. We would
> > rollforward until the xlog file time > desired point in time.
>
> I was thinkin
Simon Riggs wrote:
> Transaction log files currently have timestamps, so that is
> straightforward, but probably not the best we can do. We would
> rollforward until the xlog file time > desired point in time.
>
> To make (2) work we would have to have a timestamp associated with each
> transactio
Since Phase1 is functioning and should hopefully soon complete, we can
now start thinking about Phase 2: full recovery to a point-in-time.
Previous thinking was that a command line switch would be used to
specify recover to a given point in time, rather than the default, which
will be recover all
31 matches
Mail list logo
