| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
| Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hilbert, Sebastian" <Sebastian(dot)Hilbert(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [GENERAL] pg_upgrade ?deficiency |
| Date: | 2013-11-28 15:39:18 |
| Message-ID: | 20131128153918.GA6612@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | bricklen | 2013-11-28 16:01:26 | Re: unnest on multi-dimensional arrays |
| Previous Message | Tom Lane | 2013-11-28 15:03:47 | Re: unnest on multi-dimensional arrays |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-11-28 15:46:08 | Re: Another bug introduced by fastpath patch |
| Previous Message | Andres Freund | 2013-11-28 15:35:29 | Re: Another bug introduced by fastpath patch |