Re: [BUG] Re-entering malloc problem when use --enable-nls build postgresql
От | Tom Lane |
---|---|
Тема | Re: [BUG] Re-entering malloc problem when use --enable-nls build postgresql |
Дата | |
Msg-id | 11445.1525817759@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes: > On 2018-05-08 18:04:07 -0400, Tom Lane wrote: >> Yeah. Though now that we have the postmaster mechanism to wait-five- >> seconds-then-SIGKILL, maybe we could rethink that requirement? If we >> reimplemented SIGQUIT to work more like SIGTERM, it would surely be >> a lot safer. There would be cases where a stuck backend wouldn't >> respond and it'd eventually get SIGKILL'd, but in return we'd get rid >> of problems like this one. > Right now we intentionally do not accept interrupts in a couple places > where we want to die quickly because we're making persistent changes. I > don't think it'd be good to continue e.g. committing any longer than > possible after one process segfaulted. Well, that's an implementation question. I was sort of envisioning that we could allow CHECK_FOR_INTERRUPTS to respond to a SIGQUIT interrupt even when regular interrupts are disabled, reasoning that if we're at a CHECK_FOR_INTERRUPTS at all, then we should be someplace where it's more or less safe to trigger the exit. If we had it like that, then for example the commit sequence could put a CHECK_FOR_INTERRUPTS at the last possible moment before committing, knowing that regular interrupts are held off --- but if there's a SIGQUIT pending we'd take it. regards, tom lane
В списке pgsql-bugs по дате отправления: