Have a good evening...
On Tue, 2004-05-11 at 22:26, Alvaro Herrera wrote:
recovery points are transaction commit/abort, not transaction start.
Agreed.On Tue, May 11, 2004 at 09:25:37PM +0100, Simon Riggs wrote:
Both xact commit and abort have timestamps in the XLog. I think validOn Tue, 2004-05-11 at 16:33, Bruce Momjian wrote:
Tom Lane wrote:
Tom Lane wrote:
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
recovery points are transaction commit/abort, not transaction start.
If we go searching for a particular Xid, there is no way to tell whether
an Xid suggested by a user is too big or too small for use as a recovery
target. We need to recover - it is the only way to tell; if we find an
Xid that matches, we stop. If not, we keep going until end of logs, when
we need to issue a "recovered fully - the Xid you gave was not valid",
which may take some time and is also very clearly not what was wanted.
I think the user should first examine the logs with whatever tools arean Xid suggested by a user is too big or too small for use as a recovery
target. We need to recover - it is the only way to tell; if we find an
Xid that matches, we stop. If not, we keep going until end of logs, when
we need to issue a "recovered fully - the Xid you gave was not valid",
which may take some time and is also very clearly not what was wanted.
provided, and use a timestamp or a Xid listed in the XLog. If they use
a Xid that's not listed, it's not our fault ...
worries.
b) later, a utility that allowed xlogs to be inspected to allow DBA to
decide which is the correct Xid to recover to.
Why is this difficult? There are lots of subsys_desc() functions whichdecide which is the correct Xid to recover to.
already returns what's in each log record as a string. The tool could
initially just dump that ...
Therefore: action on me? - add a timestamp to EACH xlog record -
something I had been shying away from.
You only need timestamps in xl_xact_commit and xl_xact_abort, which aresomething I had been shying away from.
already there.
On Tue, 2004-05-11 at 14:56, Alvaro Herrera wrote:
(Unrelated: note that after main transaction commit, a committed
subtransaction is indistinguishable from a committed main transaction --
and with the current idea of XLog I have, after recovering a transaction
tree from XLog there won't be any mark in pg_subtrans. So the system
will not be exactly as it was before but it won't matter.)
I don't think we need a subtrans commit directly, since if the top-level(Unrelated: note that after main transaction commit, a committed
subtransaction is indistinguishable from a committed main transaction --
and with the current idea of XLog I have, after recovering a transaction
tree from XLog there won't be any mark in pg_subtrans. So the system
will not be exactly as it was before but it won't matter.)
commits after the subtrans has committed, then we're good.
we need to recover the pg_clog write.
However, if a subtrans aborts, yet the top-level commits there will be
data written to the database about an aborted transaction. We don't have
Undo, so the subtrans clog must be updated to show that the subtrans
aborted, otherwise we would read both the committed (top-level) and the
uncommitted data (subtrans).
If the aborted subxact wrote a tuple, its Xid has to be in the pg_clog.
Another way of putting it - if it was worth writing before a crash, it
is worth recovering after a crash. Surely?
Right. What I was saying is that we don't need pg_subtrans info,data written to the database about an aborted transaction. We don't have
Undo, so the subtrans clog must be updated to show that the subtrans
aborted, otherwise we would read both the committed (top-level) and the
uncommitted data (subtrans).
If the aborted subxact wrote a tuple, its Xid has to be in the pg_clog.
Another way of putting it - if it was worth writing before a crash, it
is worth recovering after a crash. Surely?
because that's only needed while the subtransaction is marked as
"subcommitted" but it's parent hasn't committed or aborted yet. The
subcommitted status is changed to committed/aborted when the main
transaction commits or aborts; at recovery time, we already know if that
happenned or not so we can mark it right away.
Surely it is possible that a subtrans could abort, yet the fulltrans
commits. Yet that doesn't in any way imply that the subtrans should
change from aborted to committed?
Anyway, I've raised my thoughts, so if you're still OK, thats fine by
me. I'll get back to the wheel to see what can be spun...
Best regards, Simon Riggs
