Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Date
Msg-id 20616.1208447522@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory
Next
From: Tom Lane
Date:
Subject: Re: count(*) performance improvement ideas