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 <alvherre@dcc.uchile.cl> writes:
Both xact commit and abort have timestamps in the XLog. I think valid
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 are
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 ...
Blame is in the eye of the beholder. Anyway, because of above, no
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 which
already returns what's in each log record as a string. The tool could
initially just dump that ...
It's not hard, its all a question of finite time resources.
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 are
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
commits after the subtrans has committed, then we're good.
If the subxact wrote a tuple, its Xid has to be in the pg_clog. Thus
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,
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.
Maybe I'm just not following you, which seems likely.

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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 16 of 23 | next ›
Discussion Overview
grouppgsql-hackers @
postedMay 10, '04 at 11:13p
activeMay 12, '04 at 9:20a



site design / logo © 2021 Grokbase