From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Subject: | Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
Date: | 2008-04-17 15:52:02 |
Message-ID: | 20616.1208447522@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Heikki Linnakangas wrote:
>> Sorry if I missed it in the original thread, but what is the use case
>> you have in mind?
> I think the bottom line is just that having statement_timeout a global setting
> is stupid for a variety of reasons (dump, restore, vacuum, locks, incidental
> delays) that we should discourage it (or prevent it, as proposed elsewhere)
> rather than working around it in countless individual places.
I'm not convinced that there's no use-case for global statement_timeout,
and even less convinced that there won't be anyone setting one anyway.
Unless we are prepared to somehow *prevent* such a setting from being
put in place, the proposed patch seems reasonable to me.
Unless you have a use-case in which it's actually desirable for the dump
or restore to fail. I'm having a tough time imagining one though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-17 16:00:52 | Re: count(*) performance improvement ideas |
Previous Message | Tom Lane | 2008-04-17 15:48:41 | Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory |
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2008-04-17 16:21:36 | Multiline privileges in \z |
Previous Message | Bruce Momjian | 2008-04-17 14:07:13 | Re: Proposed patch - psql wraps at window width |