Tom Lane < tgl(at)sss(dot)pgh(dot)pa(dot)us > wrote:
> Hmm. This patch disallows the case of creating a read-only
> subtransaction of a read-write parent. That's a step backwards.
> I'm not sure how we could enforce that the property not change
> after the first query of a subxact, but maybe we don't care that
> much? Do your optimizations pay attention to local read-only in a
> subxact?
No, it's all about the top level transaction, as long as the
subtransaction doesn't do anything which violates the requirements
of the top level. (That is, if the top level is not READ ONLY, I
can't do the optimizations, but it would cause no problem if a
subtransaction was READ ONLY -- it just wouldn't allow any special
optimizations.)
I noticed that the standard seems (if I'm reading it correctly) to
allow subtransactions to switch to more restrictive settings for
both transaction isolation and read only status than the enclosing
transaction, but not looser. I don't think it makes sense in
PostgreSQL to say (for example) that the top level transaction is
READ COMMITTED but the subtransaction is SERIALIZABLE, but it might
make sense to say that the top level transaction is READ WRITE but
the subtransaction is READ ONLY. And I see where I broke support
for that in the patch.
I can fix up the patch if to support it again if you like. (I think
it's just a matter of replacing a few lines that I replaced in the
original patch.) If you'd rather do it, I'll stay out of your way.
-Kevin