On Mon, Jan 24, 2011 at 2:21 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
