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+TgmoY+93GrC6CH=hAwEY+y9Pd69Thoc4WVwQCo8KVfYu3JvA@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 Mon, Jan 13, 2020 at 3:00 PM Stephen Frost <sfrost@snowman.net> wrote:
> I've never heard that and I don't agree with it being a justification
> for blocking sensible progress.

Speaking of sensible progress, I think we've drifted off on a tangent
here about ALTER SYSTEM. As I understand it, nobody's opposed to the
most recent version (v3) of the proposed patch, which also makes no
definitional changes relative to the status quo, but does fix some
bugs, and makes things a little nicer for parallel query, too. So I'd
like to go ahead and commit that.

Discussing of what to do about ALTER SYSTEM can continue, although I
feel perhaps the current discussion isn't particularly productive.  On
the one hand, the argument that it isn't read only because it writes
data someplace doesn't convince me: practically every command can
cause some kind of write some place, e.g. SELECT can write WAL for at
least 2 different reasons, and that does not make it not read-only,
nor does the fact that it updates the table statistics. The question
of what data is being written must be relevant. On the other hand, I'm
unpersuaded by the arguments so far that including ALTER SYSTEM
commands in pg_dump output would be anything other than a train wreck,
though doing it optionally and not by default might be OK. However,
the main thing for me is that messing around with the behavior of
ALTER SYSTEM in either of those ways or some other is not what this
patch is about. I'm just proposing to refactor the code to fix the
existing bugs and make it much less likely that future patches will
create new ones, and I think reclassifying or redesigning ALTER SYSTEM
ought to be done, if at all, separately.

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



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Create/alter policy and exclusive table lock
Next
From: Julien Rouhaud
Date:
Subject: Re: Add pg_file_sync() to adminpack