On Thu, Oct 26, 2017 at 7:10 PM, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > FIX > ============================== > > Add the check "CurrentMemoryContext != NULL" in write_eventlog() as in > write_console().
* Also verify that we are not on our way into error recursion trouble due * to error messages thrown deep inside pgwin32_message_to_UTF16(). */ if (!in_error_recursion_trouble() && + CurrentMemoryContext != NULL && GetMessageEncoding() != GetACPEncoding()) { So you are basically ready to lose any message that could be pushed here if there is no memory context? That does not sound like a good trade-off to me. A static buffer does not look like the best idea either to not truncate message, so couldn't we envisage to just use malloc? pgwin32_message_to_UTF16() is called in two places in elog.c, and there is a full control on the error code paths. > NOTE > ============================== > > The reason is for not outputing the crash dump is a) the crash occurred > before installing the Windows exception handler > (pgwin32_install_crashdump_handler() call) and b) the effect of the following > call in postmaster is inherited in the child process. > > /* In case of general protection fault, don't show GUI popup > box */ > SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); > > But I'm not sure in what order we should do > pgwin32_install_crashdump_handler(), startup_hacks() and steps therein, > MemoryContextInit(). I think that's another patch. Perhaps. I don't have a final opinion on this matter. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers