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

Re: [GENERAL] main log encoding problem

From: Alexander Law <exclusion(at)gmail(dot)com>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-general(at)postgresql(dot)org, ringerc(at)ringerc(dot)id(dot)au, yi(dot)codeplayer(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [GENERAL] main log encoding problem
Date: 2012-07-19 11:50:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-generalpgsql-hackers
> I like Craig's idea of adding the client encoding to the log lines. A
> possible problem with that (I'm not an encoding expert) is that a log
> line like that will contain data about the database server meta-data
> (log time, client encoding, etc) in the database default encoding and
> database data (the logged query and user-supplied values) in the
> client encoding. One option would be to use the client encoding for
> the entire log line, but would that result in legible meta-data in
> every encoding?
I think then we get non-human readable logs. We will need one more tool 
to open and convert the log (and omit excessive encoding specification 
in each line).
> It appears that the primarly here is that SQL statements and
> user-supplied data are being logged, while the log-file is a text file
> in a fixed encoding.
Yes, and in in my opinion there is nothing unusual about it. XML/HTML 
are examples of a text files with fixed encoding that can contain 
multi-language strings. UTF-8 is the default encoding for XML. And when 
it's not good enough (as Tatsou noticed), you still can switch to another.
> Perhaps another solution would be to add the ability to log certain
> types of information (not the core database server log info, of
> course!) to a database/table so that each record can be stored in its
> own encoding?
> That way the transcoding doesn't have to take place until someone is
> reading the log, you'd know what to transcode the data to (namely the
> client_encoding of the reading session) and there isn't any issue of
> transcoding errors while logging statements.
I don't think it would be the simplest solution of the existing problem. 
It can be another branch of evolution, but it doesn't answer the 
question - what encoding to use for the core database server log?

In response to


pgsql-hackers by date

Next:From: Alban HertroysDate: 2012-07-19 12:16:10
Subject: Re: [GENERAL] main log encoding problem
Previous:From: Andres FreundDate: 2012-07-19 10:29:03
Subject: [PATCH] XLogReader v2

pgsql-bugs by date

Next:From: Noah MischDate: 2012-07-19 11:53:15
Subject: Re: BUG #6712: PostgreSQL 9.2 beta2: alter table drop constraintdoes not work on inherited master table
Previous:From: Alexander LawDate: 2012-07-19 09:33:01
Subject: Re: main log encoding problem

pgsql-general by date

Next:From: Alban HertroysDate: 2012-07-19 12:16:10
Subject: Re: [GENERAL] main log encoding problem
Previous:From: Edson RichterDate: 2012-07-19 11:45:41
Subject: Synchronization Master -> Slave (on slow connetion)

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