Re: our checks for read-only queries are not great - Mailing list pgsql-hackers

From Robert Haas
Subject Re: our checks for read-only queries are not great
Date
Msg-id CA+Tgmoa3p0OisjWfSsPMOv5z19PcvqUJHdvZ26_v2cQB_o5oPQ@mail.gmail.com
Whole thread Raw
In response to Re: our checks for read-only queries are not great  (Stephen Frost <sfrost@snowman.net>)
Responses Re: our checks for read-only queries are not great  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 8, 2020 at 5:57 PM Stephen Frost <sfrost@snowman.net> wrote:
> Yeah, I don't like the WEAKLY_READ_ONLY idea either- explicitly having
> COMMAND_OK_IN_X seems cleaner.

Done that way. v2 attached.

> Would we be able to make a rule of "can't change on-disk stuff, except
> for things in temporary schemas" and have it stick without a lot of
> complaints?  Seems like that would address Tom's ALTER SYSTEM SET
> concern, and would mean CLUSTER/REINDEX/VACUUM are disallowed in a
> backwards-incompatible way (though I think I'm fine with that..), and
> SET would still be allowed (which strikes me as correct too).  I'm not
> quite sure how I feel about LISTEN, but that it could possibly actually
> be used post-promotion and doesn't change on-disk stuff makes me feel
> like it actually probably should be allowed.

I think we can make any rule we like, but I think we should have some
measure of broad agreement on it. I'd like to go ahead with this for
now and then further changes can continue to be discussed and debated.
Hopefully we'll get a few more people to weigh in, too, because
deciding something like this based on what a handful of people doesn't
seem like a good idea to me.

I'd be really interested to hear if anyone knows the history behind
allowing CLUSTER, REINDEX, VACUUM, and some operations on temp tables.
It seems to have been that way for a long time. I wonder if it was a
deliberate choice or something that just happened semi-accidentally.

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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
Next
From: Robert Haas
Date:
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions