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 | 840.1525757553@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | [BUG] Re-entering malloc problem when use --enable-nls build postgresql ("158306855" <anderson2013@qq.com>) |
| Ответы |
Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql
|
| Список | pgsql-bugs |
"=?ISO-8859-1?B?MTU4MzA2ODU1?=" <anderson2013@qq.com> writes:
> I found that compiling postgresql with enable-nls may be introduce a problem
> 1. When build postgresql with enable-nls (Native Language Support), postgresql use dgettext function to translate
Language.
> 2. The quickdie use dgettext translate message ; dgettext use malloc (in __dcigettext function)
> 3. When use pg_ctl -m fast to shutdown postgresql, pg backend process use function quickdie to shutdown database.
> 4. Before receive quickdie signal, if backend process in malloc function and already have lock that will lead to
processdeadlock.
I can't get excited about this. quickdie's attempt to report that it's
killing the process is necessarily a "best effort" undertaking, because
we cannot be sure that the process is in a good state. In this situation,
it isn't. --enable-nls might make the odds of that a bit worse, but we
could get such a failure regardless.
There are not any better alternatives. We can't just set a flag in the
signal handler and hope that control will someday reach a place that
notices the flag. We could exit without attempting to report anything,
but nobody would find that user-friendly. So we try to report, in the
full understanding that sometimes it won't work. That's one reason why
the postmaster has a timeout-and-then-hard-SIGKILL behavior.
regards, tom lane
В списке pgsql-bugs по дате отправления: