> It'd be fairly unproblematic to write an untranslated message out. There
> we can make sure to either only use plain syscalls or use memory from
> the preallocated context. I think it'd be ok to not to translate in
> that situation.
I agree with this solution when build postgres with enable-nls.
------------------ Original ------------------
From: "Andres Freund"<andres@anarazel.de>;
Date: Tue, May 8, 2018 01:57 PM
To: "Tom Lane"<tgl@sss.pgh.pa.us>;
Cc: "158306855"<anderson2013@qq.com>; "pgsql-bugs"<pgsql-bugs@lists.postgresql.org>;
Subject: Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql
On 2018-05-08 01:32:33 -0400, Tom Lane wrote:
> "158306855" <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 process deadlock.
I don't think it's realistic to treat this is something we'll
necessarily backpatch. Any fix is going to be too complicated.
> 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.
As previously, I disagree with this. There's plenty ways to reach
quickdie, several where we are quite sure about the state. -m immediate
is a thing, and there's plenty situations where it's an entirely
reasonable choice.
> 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.
It'd be fairly unproblematic to write an untranslated message out. There
we can make sure to either only use plain syscalls or use memory from
the preallocated context. I think it'd be ok to not to translate in
that situation.
We should also use _exit or the like when exiting quickly, calling exit
handlers from a signal handlers is a bad bad idea.
Greetings,
Andres Freund
