Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up
Date
Msg-id CAB7nPqTOcb7UmR_1_GkwpY1Mv6TG4ZVaoRVkDrPgsTiXfHnt1Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Linking libpq statically to libssl
Next
From: Nikita Glukhov
Date:
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL