Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up |
Дата | |
Msg-id | CAB7nPqTOcb7UmR_1_GkwpY1Mv6TG4ZVaoRVkDrPgsTiXfHnt1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up
|
Список | pgsql-hackers |
On Wed, Nov 1, 2017 at 12:07 AM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > From: Michael Paquier [mailto:michael.paquier@gmail.com] >> On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki >> <tsunakawa.takay@jp.fujitsu.com> wrote: >> > When CurrentMemoryContext is NULL, the message is logged with >> ReportEventA(). This is similar to write_console(). >> >> My point is that as Postgres is running as a service, isn't it wrong to >> write a message to stderr as a fallback if the memory context is not set? >> You would lose a message. It seems to me that for an operation that can >> happen at a low-level like the postmaster startup, we should really use >> a low-level operation as well. > > I'm sorry I may not have been clear. With this patch, write_eventlog() outputs the message to event log with ReportEventA()when CurrentMemoryContext is NULL. It doesn't write to stderr. So the message won't be lost. Oh, yes. Sorry. I got confused a bit by write_eventlog(), which is already doing what your patch is adding for write_eventlog(). I am switching the patch as ready for committer, I definitely agree that you are taking the write approach here. I am also adding Noah to get some input on this issue, as he is the author and committer of 5f538ad0 which has improved the handling of non-ASCII characters in this code path, and more importantly has tweaked 43adc7a7 to handle properly transaction contexts in pgwin32_message_to_UTF16() which is where the palloc calls happen. I would be the one in the pool of committers who would most likely commit your patch. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: