Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> One thing to watch for is allowing subxact exit to restore the
> previous read-write state.
OK.
> BTW it looks like assign_XactIsoLevel emits a rather useless debug
> message in that case, so that code could stand some cleanup too.
I'll take a look.
> Also, that code is set so that it will throw an error even if
> you're assigning the currently active setting, which maybe is
> overly strict? Not sure.
The standard is tricky to read, but my reading of it is that only
"LOCAL" changes are allowed after the transaction is underway (which
I *think* effectively means a subtransaction), and those can't make
the setting less strict -- you're allowed to specify the same level
or more strict. There would be no harm from the perspective of
anything I'm working on to allow an in-progress transaction to be
set to what it already has, but that seems to invite confusion and
error more than provide a helpful feature, as far as I can tell.
I'm inclined not to allow it except at the start of a
subtransaction, but don't feel strongly about it.
>> I can fix up the patch if to support it again if you like.
> Feel free to have a go at it.
Will do. I notice that I also removed the check for
RecoveryInProgress(), which I will also restore. And maybe a
regression test or two for the subtransaction usages....
-Kevin