Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
От | daveg |
---|---|
Тема | Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
Дата | |
Msg-id | 20080625000103.GD12245@sonic.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
|
Список | 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 по дате отправления: