perplexing error message

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: perplexing error message
Date: 2015-02-07 21:07:45
Message-ID: CA+TgmoYAe-YtnwRbJz03RHwkKEtMdfeqhrFNWA5EdDxEUmr+6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

There are a lot of things that are understandably forbidden in a
read-only transaction, but one would not expect SELECT to be among
them. And yet, one can get the system to complain about precisely
that:

rhaas=# create table rules_src(f1 int, f2 int);
ERROR: relation "rules_src" already exists
rhaas=# create table rules_log(f1 int, f2 int, tag text);
ERROR: relation "rules_log" already exists
rhaas=# insert into rules_src values(1,2), (11,12);
INSERT 0 2
rhaas=# create rule r2 as on update to rules_src do also
rhaas-# values(old.*, 'old'), (new.*, 'new');
ERROR: rule "r2" for relation "rules_src" already exists
rhaas=# begin transaction read only;
BEGIN
rhaas=# update rules_src set f2 = f2 / 10;
ERROR: cannot execute SELECT in a read-only transaction

It sees fair for this to fail; I am after all attempting an update
inside of a read-only transaction. But it is mighty strange to
complain about SELECT, since (1) the example contains exactly 0
instances of the keyword SELECT and (2) SELECT is a read-only
operation. Changing "do also" to "do instead" produces the same
failure. This seems to be the result of this code in
ExecCheckXactReadOnly:

if ((rte->requiredPerms & (~ACL_SELECT)) == 0)
continue;

...

PreventCommandIfReadOnly(CreateCommandTag((Node *) plannedstmt));

There's nothing obviously stupid about that, but the results in this
case don't make much sense.

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-02-07 21:30:29 Re: Parallel Seq Scan
Previous Message Paul Jungwirth 2015-02-07 19:01:48 Re: How do I bump a row to the front of sort efficiently