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
