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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
