Re: serializable read only deferrable

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

Hmm ...

(1) If the standard says that you're allowed to apply a redundant setting,
I think we'd better accept that.

(2) I'm not thrilled about the idea of tracking the equivalent of
FirstSnapshotSet for each subtransaction, which I think would be
necessary infrastructure to error-check this as tightly as you seem to
have in mind. I'd prefer to be a bit laxer in order to have less
overhead for what is in the end just nanny-ism. So the implementation
I had in mind would allow SET TRANSACTION operations to occur later in a
subxact, as long as they were redundant and weren't actually trying to
change the active value.

regards, tom lane