Skip site navigation (1) Skip section navigation (2)

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

From: Alexander Law <exclusion(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console
Date: 2013-01-30 06:00:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-generalpgsql-hackers
30.01.2013 05:51, Noah Misch wrote:
> On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
>> Alexander Law <exclusion(at)gmail(dot)com> writes:
>>> Please look at the following l10n bug:
>>> 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.


In response to


pgsql-hackers by date

Next:From: Jeevan ChalkeDate: 2013-01-30 06:52:33
Subject: Re: pg_dump --pretty-print-views
Previous:From: Josh BerkusDate: 2013-01-30 05:07:45
Subject: Re: pg_ctl idempotent option

pgsql-bugs by date

Next:From: Pavan DeolaseeDate: 2013-01-30 08:15:56
Subject: Re: BUG #7834: Overflow with limited information provided
Previous:From: Noah MischDate: 2013-01-30 01:51:55
Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console

pgsql-general by date

Next:From: Alexander FarberDate: 2013-01-30 07:41:40
Subject: Re: Optimizing select count query which often takes over 10 seconds
Previous:From: Groshev AndreyDate: 2013-01-30 05:23:22
Subject: trouble with upgrade from 9.0 (many schemas and tables)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group