Re: READ ONLY fixes

On Mon, Jan 24, 2011 at 2:21 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> I am wondering if it wouldn't be simpler and more logical to allow
>> idempotent changes of these settings at any time, and to restrict
>> only changes that actually change something.  It feels really
>> weird to allow changing these properties to their own values at
>> any time within a subtransaction, but not in a top-level
>> transaction.
>
> I just looked at the committed code, and saw that it not only
> changed things in this regard, but also allows a change from READ
> WRITE to READ ONLY at any point in a transaction.  (I see now that
> your pseudo-code did the same, but I didn't pick up on it at the
> time.)
>
> That part of it seems a little weird to me.  I think I can live with
> it since it doesn't open up any routes to break SSI (now that I
> reviewed our use of XactReadOnly and tweaked a function), or to
> subvert security except for the unlikely scenario that something is
> checking RO state and depending on there having been no writes
> earlier in the transaction -- in which case they'd still need to be
> very careful about subtransactions.
>
> In short, I'm OK with it but wanted to make sure the community was
> aware of the change to what this patch was doing, because I don't
> think the discussion made that entirely clear.

Hmm, sorry, I thought that had been made clear. I guess the issue is
that within a subtransaction we can't really prohibit that anyway, so
spending extra code to do it in a toplevel transaction seems like
making the code more complicated just for the heck of it. I wasn't
intending to do anything not agreed...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company