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
> > XLOG_HEAP_MOVE records, or "unused" data in XLOG_HEAP_CLEAN.
Got it. I had skimmed looking for an example of this but didn't find
this.
> Should we write a subtrans commit record when WAL_DEBUG is set? We could
> remove it completely in the future when the interaction between PITR
> recovery and subtransactions have been fully covered off.
Actually, the only thing a subtransaction has to recover is mark its Xid
as either committed of aborted in clog, and possible file deletions, so
there shouldn't be too much interaction with your work.
(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.)
> My thinking is that subtransactions themselves are not valid recovery
> targets. As long as we can tell the top level commits from the
> subtransactions then it should be easy to recover. My thinking is that
> if a subtransaction id is wrongly quoted as a recover point, then this
> would be treated as a "rollforward to txnid X, but do not include this
> one". Does that make sense? Does everything we have support that?
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.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La gente vulgar solo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"