Andres Freund <and...@2ndquadrant.com> wrote: > FWIW, I am less than convinced that it is correct for > pg_dump[all] to emit SET default_transaction_readonly = off;
It doesn't change the database setting, just the connection which is issuing commands to create global object -- ones that don't reside in the database we are connected to. As the comment in pg_dumpall.c says, right above where I added this: /* * We used to emit \connect postgres here, but that served no purpose * other than to break things for installations without a postgres * database. Everything we're restoring here is a global, so whichever * database we're connected to at the moment is fine. */ > The user might explicitly have set that to prevent against > somebody restoring into the wrong database or somesuch. Why is it > our business to override such decisions? Hmm. If your argument had been that the user intended that the database be a read-only database, then I would say that your argument held no water. Any user can choose to make any transaction (or all subsequent transactions on the connection) read-write any time they want. The problem with pg_dumpall as it stands is that it sets the databases to that default and then tries to load data into them, which fails. But you have a point regarding adding what I proposed to pg_dump. The more I think about it, the more I'm inclined to think that pg_dumpall should insert this right after the \connect to a database it is going to write to, rather than affecting pg_dump output at all. That would allow you default protection against writing pg_dump output to a database that was flagged this way. You could get around it by connecting interactively with psql, issuing a SET command, and bringing in dump output with \i from a text file. If we go this way, would we want options on pg_restore and/or psql to issue this set when reading in a file (or piped input)? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
