On Sat, Nov 23, 2013 at 08:44:42AM -0800, Kevin Grittner wrote:
> Here's my problem with that. Here's setup to create what I don't
> think is all that weird a setup:
...
> The following appears to produce a good backup, since there is no
> error:
...
> Now we attempt to restore what we thought was a good backup:
>
> psql postgres <~/dumpall.sql
>
> What we get is:
> ERROR: cannot execute COMMENT in a read-only transaction
> ERROR: cannot execute CREATE EXTENSION in a read-only transaction
> ERROR: cannot execute COMMENT in a read-only transaction
> ERROR: cannot execute REVOKE in a read-only transaction
> ERROR: cannot execute REVOKE in a read-only transaction
> ERROR: cannot execute GRANT in a read-only transaction
> ERROR: cannot execute GRANT in a read-only transaction
...
> ERROR: cannot execute CREATE SCHEMA in a read-only transaction
> ERROR: cannot execute ALTER SCHEMA in a read-only transaction
> ERROR: cannot execute CREATE EXTENSION in a read-only transaction
> ERROR: cannot execute COMMENT in a read-only transaction
...
> If the dump is made with the attached patch, you get this on
> restore:
...
> The cluster is created in the state that was dumped, default read
> only flags and all.
I find the patched behaviour more conformant
with the Principle Of Least Astonishment.
Maybe I am splitting hairs but setting transactions to readonly
per default does not mean the database *as such* is to be readonly.
It literally applies to the *default* state of transactions (as
opposed to the ONLY state of transactions). No more, no less.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
