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" ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
