On Sun, 15 Jul 2007, Tom Lane wrote: > "Affan Salman" <[EMAIL PROTECTED]> writes: > > With some time to spare, I thought I'd submit a quick-fix patch to the > > issue I reported here: > > http://archives.postgresql.org/pgsql-hackers/2007-07/msg00339.php > > I don't think this is right. If the original tuple was inserted by a > subtransaction of our transaction, it will have been checked at > subtransaction subcommit, no? ISTM what we need is to schedule the > on-UPDATE trigger if the original tuple was inserted by either our > current (sub)transaction or one of its parents, and those are not the > semantics of TransactionIdIsCurrentTransactionId, unfortunately. > > Stephan, have you looked at this bug report? What do you think?
I don't think the subtransaction subcommit will do the check. Unless I'm missing something about the code, a CommitTransaction would but a CommitSubTransaction won't, which actually makes sense given that we're mapping savepoints on to it, and I don't think we are allowed to check at savepoint release time. I tried a few small ariations on the given example, all of which fail on my 8.2.4 machine, including the following, but maybe I've missed the scenario you're envisioning: begin; savepoint i1; insert ... ; release i1; savepoint u1; update ...; release u1; commit; begin; savepoint i1; insert ... ; release i1; savepoint u1; update ...; commit; begin; savepoint a1; savepoint a2; insert ...; release a2; update ...; commit; begin; savepoint a1; savepoint a2; insert ...; release a2; savepoint a3; update ...; commit; ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate