Re: Parallel pg_dump's error reporting doesn't work worth squat
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Parallel pg_dump's error reporting doesn't work worth squat |
| Дата | |
| Msg-id | 11515.1464961470@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Parallel pg_dump's error reporting doesn't work worth squat (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
| Ответы |
Re: Parallel pg_dump's error reporting doesn't work
worth squat
|
| Список | pgsql-hackers |
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> For sure, any of the "dangers" of TerminateThread don't matter
> for this case.
I think that this one:
>> If the target thread is allocating memory from the heap, the heap
>> lock will not be released.
is potentially a hazard, which is why I made sure to use write_stderr
later on in the console interrupt handler. Your original suggestion
to use write_msg would end up going through fprintf, which might well
use malloc internally. (It's possible that Windows' version of write()
could too, I suppose, but that's probably as low-level as we are
going to get.)
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера