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