On Sun, 15 Jul 2007, Tom Lane wrote:
> "Affan Salman" <affan@enterprisedb.com> 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;