Jeff Davis <pg...@j-davis.com> wrote: > Oh, I see the distinction you're making: in PL/pgSQL, the > exception mechanism involves *implicit* subtransaction rollbacks. > That's more of a language issue, but a valid point. I think it holds for the general case of functions -- there's no reason to believe that you are aware of all subtransactions within a function or will know what was read by an aborted subtransaction within any function. It's pretty easy to describe in plpgsql, but I doubt the issue is specific to that language. > I'm still not sure I see a theoretical difference, but it does > seem wise to keep predicate locks for aborted subtransactions. I think that if it was guaranteed that application software was aware of all subtransactions and their completion states, there would still be a subtle issue as long as what was read in the subtransaction could in any way influence the behavior of subsequent steps in the enclosing transaction (or subtransaction). In essence, you have no reasonable way of knowing what the outer transaction would have done had it been able to see the work of a concurrent transaction, so you can't know whether the behavior of a set of transactions is the same as it would have been had they run one-at-a-time. A really stringent analysis of the logic of the code might be able to answer that for some cases (maybe even all cases?) but not at a reasonable cost. SSI admits that it might cause rollbacks in some cases where correctness doesn't require it, but it ensures that it will roll back enough transactions to ensure correctness and tries to do so at a reasonable cost. > I'll write something up. Can I document that you may depend on the > results read in aborted subtransactions, or should I leave that > undefined for now? Hmm. They will be read with the correct snapshot, and since we're holding predicate locks they can't show any anomalies if the final transaction complete, so I sure can't see any reason it is a problem to depend on data viewed in an aborted subtransaction. If you think that is a property that could be useful to users, I guess it should be documented. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers