From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Alexander Law <exclusion(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-06-24 22:46:08 |
Message-ID: | 20130624224608.GA839209@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general pgsql-hackers |
On Mon, Jun 24, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> 23.06.2013 20:53, Noah Misch wrote:
>> The attached revision fixes all above points. Would you look it over? The
>> area was painfully light on comments, so I added some. I renamed
>> pgwin32_toUTF16(), which ceases to be a good name now that it converts from
>> message encoding, not database encoding. GetPlatformEncoding() became unused,
>> so I removed it. (If we have cause reintroduce the exact same concept later,
>> GetTTYEncoding() would name it more accurately.)
> Yes, the patch works for me. I have just a little question about
> pgwin32_message_to_UTF16. Do we need to convert SQL_ASCII through UTF8
> or should SQL_ASCII be mapped to 20127 (US-ASCII (7-bit))?
Good question. SQL_ASCII is an awkward database encoding; it actually
indicates ignorance about the significance of byte sequences in text. As a
result, nothing we do here is likely to be delightful. I caused an error
containing some LATIN2 bytes (SELECT * FROM "śmiać się") in an SQL_ASCII /
LC_CTYPE=C database, and the result was decent, considering: the event log
shows a question-mark-in-rhombus symbol for each of the non-ASCII bytes.
Using CP20127 turned it into "6miaf sij". I don't have a great idea for
improving on the existing hack.
>> What should we do for the back branches, if anything? Fixes for garbled
>> display on consoles and event logs are fair to back-patch, but users might be
>> accustomed to the present situation for SQL_ASCII databases. Given the low
>> incidence of complaints and the workaround of using logging_collector, I am
>> inclined to put the whole thing in master only.
> I thought that the change could be a first step to the PosgreSQL log
> encoding normalization. Today the log may contain messages with
> different encodings (we had a long discussion a year ago:
> http://www.postgresql.org/message-id/5007C399.6000405@gmail.com)
> Now the new function GetMessageEncoding allows to convert all the
> messages consistently. If the future log encoding fix will be considered
> as important enough to be backported, then this patch should be
> backported too.
I doubt that would prove to be back-patch material.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-06-25 03:53:08 | Re: BUG #8242: No way to debug "subquery must return only one column" error |
Previous Message | Kim Applegate | 2013-06-24 18:25:15 | Re: BUG #8245: Urgent:Query on slave failing with invalid memory alloc request size 18446744073709537559 |
From | Date | Subject | |
---|---|---|---|
Next Message | 高健 | 2013-06-25 02:07:42 | Re: Tow kinds of different result while using create index concurrently |
Previous Message | Bruce Momjian | 2013-06-24 18:20:27 | Re: pg_largeobject.sql script not run after upgrade |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-06-24 22:46:09 | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] |
Previous Message | Alvaro Herrera | 2013-06-24 22:39:12 | Re: Patch for removng unused targets |