On Wed, 2004-05-12 at 04:47, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the commit timestamp to
be gettimeofday()
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the commit timestamp to
be gettimeofday() output (seconds+microseconds) instead of just time()
output. That should be precise enough for practical purposes.
I am saying
Simon Riggs [EMAIL PROTECTED] writes:
Currently, recovery loops until end of xlogs. There is no exit condition
from the loop. There is not currently a timestamp on the xlogs -
anywhere apart from the file date on each xlog.
Sure there is: every transaction commit record (and I think abort as
On Tue, 2004-05-11 at 16:33, Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ... I think it should be forbidden to quote a subtrans Xid as
rollforward point. Not sure if that can be done though, or how to do
it.
Seems like a nonissue, unless the
Simon Riggs wrote:
During recovery, we would search for a timestamp. If found exactly,
stop. If exceeded, stop. Any transactions not committed at that point
are, as we say, out of luck. This approach has a certainty about it
that I think is much better than the error prone Xid hunting
On Tue, May 11, 2004 at 09:25:37PM +0100, Simon Riggs wrote:
On Tue, 2004-05-11 at 16:33, Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ... I think it should be forbidden to quote a subtrans Xid as
rollforward point. Not sure if that can be done
Alvaro Herrera [EMAIL PROTECTED] writes:
Both xact commit and abort have timestamps in the XLog. I think valid
recovery points are transaction commit/abort, not transaction start.
A transaction abort cannot be an interesting stop point either; you may
as well stop at the latest preceding
On Tue, 2004-05-11 at 21:29, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Currently, recovery loops until end of xlogs. There is no exit condition
from the loop. There is not currently a timestamp on the xlogs -
anywhere apart from the file date on each xlog.
Sure there is:
On Tue, 2004-05-11 at 22:01, Bruce Momjian wrote:
Anyway, I though we agreed to just get total recovery working for 7.5
and we can deal with recovery to a particular point later.
Back on target now! Regards, Simon
---(end of broadcast)---
TIP 1:
Bruce Momjian [EMAIL PROTECTED] writes:
Many transactions are going to have the same timestamp because that just
isn't precise enough to choose a particular transaction.
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the
Thanks to all of you for such swift advice and correction!
Have a good evening...
On Tue, 2004-05-11 at 22:26, Alvaro Herrera wrote:
On Tue, May 11, 2004 at 09:25:37PM +0100, Simon Riggs wrote:
On Tue, 2004-05-11 at 16:33, Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Many transactions are going to have the same timestamp because that just
isn't precise enough to choose a particular transaction.
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, May 11, 2004 at 09:25:37PM +0100, Simon Riggs wrote:
Another way of putting it - if it was worth writing before a crash, it
is worth recovering after a crash. Surely?
Right.
Wrong. Only actions that were *committed* before the crash, or in
On Tue, May 11, 2004 at 11:07:47PM +0100, Simon Riggs wrote:
On Tue, 2004-05-11 at 22:26, Alvaro Herrera wrote:
Right. What I was saying is that we don't need pg_subtrans info,
because that's only needed while the subtransaction is marked as
subcommitted but it's parent hasn't committed
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the commit timestamp to
be gettimeofday() output (seconds+microseconds) instead of just time()
output. That should be
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this argument is largely a red herring ... but if it makes you
feel better, we could change the contents of the commit timestamp to
be gettimeofday() output (seconds+microseconds) instead of just time()
On Tue, 2004-05-11 at 04:05, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
A simple idea would be to add the committed subxact Xids to the
xl_xact_commit and xl_xact_abort structs. However, this will be a
variable length array, and those structs already have variable length
On Tue, May 11, 2004 at 07:44:53AM +0100, Simon Riggs wrote:
Tom Lane wrote:
Just means you have to do some address arithmetic instead of being able
to reference the additional data as a struct member. Tedious but hardly
difficult. See for instance the handling of move data in
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ... I think it should be forbidden to quote a subtrans Xid as
rollforward point. Not sure if that can be done though, or how to do
it.
Seems like a nonissue, unless the XLOG trace makes a subtrans look the
same as a main trans, which it'd not do
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ... I think it should be forbidden to quote a subtrans Xid as
rollforward point. Not sure if that can be done though, or how to do
it.
Seems like a nonissue, unless the XLOG trace makes a subtrans look the
same as a main
On Tue, May 11, 2004 at 10:37:49AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ... I think it should be forbidden to quote a subtrans Xid as
rollforward point. Not sure if that can be done though, or how to do
it.
Seems like a nonissue, unless the XLOG trace
Alvaro Herrera [EMAIL PROTECTED] writes:
A simple idea would be to add the committed subxact Xids to the
xl_xact_commit and xl_xact_abort structs. However, this will be a
variable length array, and those structs already have variable length
arrays at the end (filenodes to drop). I don't see
Hackers,
I'm trying to figure out how to log the subtransaction operations.
A simple idea would be to add the committed subxact Xids to the
xl_xact_commit and xl_xact_abort structs. However, this will be a
variable length array, and those structs already have variable length
arrays at the end
23 matches
Mail list logo
