Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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