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

From daveg
Subject Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Date
Msg-id 20080625000103.GD12245@sonic.net
Whole thread Raw
In response to Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 24, 2008 at 05:34:50PM -0400, Tom Lane wrote:
> daveg <daveg@sonic.net> writes:
> > lock-timeout sets statement_timeout to a small value while locks are being
> > taken on all the tables. Then it resets it to default. So it could reset it
> > to whatever the new default is.
>
> "reset to default" is *surely* not the right behavior; resetting to the
> setting that had been in effect might be a bit sane.  But the whole
> design sounds pretty broken to start with.  The timer management code
> already understands the concept of scheduling the interrupt for the
> nearest of a couple of potentially active timeouts.  ISTM any patch
> intended to add a feature like this ought to extend that logic rather
> than hack around changing the values of global variables.

Are we talking about the same patch? Because I don't know what you are
refering to with "timer management code" and "scheduling the interrupt" in
the context of pg_dump.

-dg


--
David Gould       daveg@sonic.net      510 536 1443    510 282 0869
If simplicity worked, the world would be overrun with insects.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: stat() vs cygwin
Next
From: "Jaime Casanova"
Date:
Subject: Re: proposal for smaller indexes on index-ordered tables