30.01.2013 05:51, Noah Misch wrote:
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law <exclus...@gmail.com> writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
