Re: READ ONLY fixes

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: READ ONLY fixes
Date: 2011-01-24 19:21:35
Message-ID: 4D3D7CDF0200002500039B44@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-01-24 19:25:11 Re: Change pg_last_xlog_receive_location not to move backwards
Previous Message Magnus Hagander 2011-01-24 18:22:20 Re: Allowing multiple concurrent base backups