Re: [GENERAL] pg_upgrade ?deficiency - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [GENERAL] pg_upgrade ?deficiency
Date
Msg-id 20131128153918.GA6612@momjian.us
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade ?deficiency  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Responses Re: [GENERAL] pg_upgrade ?deficiency  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
List pgsql-hackers
On Thu, Nov 28, 2013 at 10:20:53AM +0100, Karsten Hilbert wrote:
> > 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) ?

Well, then we are actually using two different reasons for patching
pg_dumpall and not pg_dump.  Your reason is based on the probability of
failure, while Tom/Kevin's reason is that default_transaction_read_only
might be used to block changes to a specific database, and they want a
pg_dump restore prevented, but a pg_dumpall restore to succeed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Another bug introduced by fastpath patch
Next
From: Tom Lane
Date:
Subject: Re: Another bug introduced by fastpath patch