On Wed, Nov 27, 2013 at 09:22:50PM -0500, Bruce Momjian wrote: > Well, I can understand that, but part of the argument was that > default_transaction_read_only is not part of the database, but rather > just the transaction default: > > > Karsten wrote: > > 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. > > I ask again! > > > What is the logic that has us setting statement_timeout in > > pg_dump but default_transaction_read_only in pg_dumpall? > > Why can't I get an answer to that question?
Bruce, I can't answer that. I am not versed enough to know. All I can make sure (and hope to have made) is that the failing use case is very clear. > Is it that statement_timeout is less likely to lead to a restore failure? That seems right -- default_read_only WILL fail the restore while stmt_timeout CAN. Or rather: One of the *legitimate* settings of read_only WILL fail it. But only *insane* settings of _timeout WILL, too (like, extremely short ones). Saner settings CAN still. Yes, I do agree that it seems useful to temporarily apply a sane stmt_timeout as well. But perhaps the idea was to think of the minimal impact patch solving the immediate problem at hand (my use case) ? 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