Re: BUG #7493: Postmaster messages unreadable in a Windows console

30.01.2013 05:51, Noah Misch wrote:
> On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
>> Alexander Law <exclusion@gmail.com> writes:
>>> Please look at the following l10n bug:
>>> http://www.postgresql.org/message-id/502A26F1.6010109@gmail.com
>>> and the proposed patch.
>> That patch looks entirely unsafe to me.  Neither of those functions
>> should be expected to be able to run when none of our standard
>> infrastructure (palloc, elog) is up yet.
>>
>> Possibly it would be safe to do this somewhere around where we do
>> GUC initialization.

Looking at elog.c:write_console, and boostrap.c:AuxiliaryProcessMain, 
mcxt.c:MemoryContextInit I would place this call 
(SetDatabaseEncoding(GetPlatformEncoding())) at MemoryContextInit.
(The branch of conversion pgwin32_toUTF16 is not executed until 
CurrentMemoryContext is not null)

But I see some calls to ereport before MemoryContextInit. Is it ok or 
MemoryContext initialization should be done before?
For example, main.c:main -> pgwin32_signal_initialize -> ereport

And there is another issue with elog.c:write_stderr
if (pgwin32_is_service) then the process writes message to the windows 
eventlog (write_eventlog), trying to convert in to UTF16. But it doesn't 
check MemoryContext before the call to pgwin32_toUTF16 (as write_console 
does) and we can get a crash in the following way:
main.c:check_root -> if (pgwin32_is_admin()) write_stderr -> if 
(pgwin32_is_service()) write_eventlog -> if (if (GetDatabaseEncoding() 
!= GetPlatformEncoding() ) pgwin32_toUTF16 -> crash

So placing SetDatabaseEncoding(GetPlatformEncoding()) before the 
check_root can be a solution for the issue.

> Even then, I wouldn't be surprised to find problematic consequences beyond
> error display.  What if all the databases are EUC_JP, the platform encoding is
> KOI8, and some postgresql.conf settings contain EUC_JP characters?  Does the
> postmaster not rely on its use of SQL_ASCII to allow those values?
>
> I would look at fixing this by making the error output machinery smarter in
> this area before changing the postmaster's notion of server_encoding.
Maybe I still miss something but I thought that 
postinit.c/CheckMyDatabase will switch encoding of a messages by 
pg_bind_textdomain_codeset to EUC_JP so there will be no issues with it. 
But until then KOI8 should be used.
Regarding postgresql.conf, as it has no explicit encoding specification, 
it should be interpreted as having the platform encoding. So in your 
example it should contain KOI8, not EUC_JP characters.

Thanks,
Alexander