Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
В списке pgsql-patches по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
| Дата | |
| Msg-id | 6596.1214343290@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout (daveg <daveg@sonic.net>) |
| Ответы |
Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
|
| Список | pgsql-patches |
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.
regards, tom lane
В списке pgsql-patches по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера