Simon Riggs wrote:
I'd suggest extending the CHECKPOINT command so you can say:
CHECKPOINT text message
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
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 text message
e.g. CHECKPOINT 'starting payroll Feb04';
(I'm sure some other DBMS does this...head spinning can;t recall...)
the
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 text message
e.g. CHECKPOINT 'starting payroll Feb04';
(I'm sure some other DBMS does this...head spinning can;t recall...)
the text could just
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
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.
They are
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 started).
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
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, time isn't the
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 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 assumes they
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, but
of course that
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
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 think there should
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 where you
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 someone know the
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 to
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 mostly
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 the
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 use the
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 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 recovery
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 and you
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 have
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
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't it be
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
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
transaction.
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 thinking ---
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 would have to
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 the xlog
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 would
31 matches
Mail list logo
