Jeff Davis <pgsql@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
