Thread: Bug Pgsql
<div class="Section1"><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><span lang="EN-US"style="font-size:10.0pt;font-family: "Courier New CYR"">Hi to all, </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR"size="2"><span lang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR""> </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><spanlang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">I came across a problem while switching from 8.0 to 8.1.4 (or, now, to 8.2.4). Here it is:</span></font><pclass="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><span lang="EN-US"style="font-size:10.0pt;font-family: "Courier New CYR""> </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><spanlang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">QUOTE: Some users are having problems loading UTF-8 data into 8.1.X. This is because previous versionsallowed invalid UTF-8 byte sequences to be entered into the database, and this release properly accepts only validUTF-8 sequences. One way to correct a dumpfile is to run the command iconv -c -f UTF-8 -t UTF-8 -o cleanfile.sql dumpfile.sql.The -c option removes invalid character sequences. A diff of the two files will show the sequences that areinvalid. iconv reads the entire input file into memory so it might be necessary to use split to break up the dump intomultiple smaller files for processing. </span></font><p class="MsoNormal" style="text-autospace:none"><font face="CourierNew CYR" size="2"><span lang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR""> </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><spanlang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">This quotation deals with receiving an inserts pack as ‘plain text’. Well, well, but here we come to anotherproblem: if a database is bulky, it ‘does not want’ to be loaded as plain text, and it requires choosing another dataformat. After this I made a backup with ‘-Ft’. But we can not simply put ‘tar’ through ‘iconv’ , so I unarchived it andmade a ‘find ./ -exec iconv’. Well, after all this I could not put it all back together so that ‘pg_restore’ would notfind it incorrect. I had to make a ‘ls | cat | psql databasename’. After 15 hours of work nothing changed! :) </span></font><pclass="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><span lang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR""> </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><spanlang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">Also, there is an error in ‘select * from table1 where lower(field[1]) like 'test' ‘. It looks like this:</span></font><pclass="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><span lang="EN-US"style="font-size:10.0pt;font-family: "Courier New CYR""> </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><spanlang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">ERROR: invalid byte sequence for encoding "UTF 8"</span></font><p class="MsoNormal" style="text-autospace:none"><fontface="Courier New CYR" size="2"><span lang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">HINT: This error can also happen if the byte sequence does not match the encoding expected by the server,which is controlled by "client_encoding".</span></font><p class="MsoNormal" style="text-autospace:none"><font face="CourierNew CYR" size="2"><span lang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR""> </span></font><p class="MsoNormal" style="text-autospace:none"><font face="Courier New CYR" size="2"><spanlang="EN-US" style="font-size:10.0pt;font-family: "Courier New CYR"">This error occurs only when we make inquiries with ‘lower/upper’ for tables containing massives, and inall other cases it is working properly.</span></font><p class="MsoNormal" style="text-autospace:none"><font face="CourierNew" size="2"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""> </span></font><p class="MsoNormal"><fontface="Courier New" size="2"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">Haveyou ever come upon such a mistake? How did you get over it?</span></font><font face="Arial" size="2"><span lang="EN-US"style="font-size:10.0pt;font-family:Arial"></span></font><p class="MsoNormal"><font face="Arial" size="2"><spanlang="EN-US" style="font-size: 10.0pt;font-family:Arial"> </span></font><p class="MsoNormal"><em><i><font face="Arial" size="2"><span style="font-size:10.0pt; font-family:Arial">*****************************************</span></font></i></em><p class="MsoNormal"><em><i><font face="Arial"size="2"><span style="font-size:10.0pt; font-family:Arial">Старший администратор ОСА УИТ </span></font></i></em><p class="MsoNormal"><em><i><font face="Arial"size="2"><span style="font-size:10.0pt; font-family:Arial">ОАО "ИнвестКапиталБанк" </span></font></i></em><p class="MsoNormal"><em><i><font face="Arial" size="2"><spanstyle="font-size:10.0pt; font-family:Arial">Казорез Александр Олегович </span></font></i></em><p class="MsoNormal"><em><i><font face="Arial" size="2"><spanstyle="font-size:10.0pt; font-family:Arial">(347)291-37-60, вн. 2021</span></font></i></em><p class="MsoNormal"><font face="Arial" size="2"><spanstyle="font-size:10.0pt; font-family:Arial"><a href="mailto:a.kazorez@investcapitalbank.ru"><em><i><font color="black" face="Arial"><span style="font-family:Arial;color:windowtext; text-decoration:none">a.kazorez@investcapitalbank.ru</span></font></i></em></a></span></font><p class="MsoNormal"><em><i><fontface="Arial" size="2"><span style="font-size:10.0pt; font-family:Arial">ICQ 400-475-046</span></font></i></em><p class="MsoNormal"><em><i><font face="Arial" size="2"><span style="font-size:10.0pt; font-family:Arial">*****************************************</span></font></i></em><p class="MsoNormal"><font face="TimesNew Roman" size="3"><span style="font-size: 12.0pt"> </span></font></div>
Hi, try this: dump your db create a db in sqlascii import into new one export from new one and then try to import in utf8. i try somethng like this in 8.1. good luck. ÐазоÑез ÐлекÑÐ°Ð½Ð´Ñ ÐÐ»ÐµÐ³Ð¾Ð²Ð¸Ñ wrote: > > Hi to all, > > I came across a problem while switching from 8.0 to 8.1.4 (or, now, to > 8.2.4). Here it is: > > QUOTE: Some users are having problems loading UTF-8 data into 8.1.X. > This is because previous versions allowed invalid UTF-8 byte sequences > to be entered into the database, and this release properly accepts > only valid UTF-8 sequences. One way to correct a dumpfile is to run > the command iconv -c -f UTF-8 -t UTF-8 -o cleanfile.sql dumpfile.sql. > The -c option removes invalid character sequences. A diff of the two > files will show the sequences that are invalid. iconv reads the entire > input file into memory so it might be necessary to use split to break > up the dump into multiple smaller files for processing. > > This quotation deals with receiving an inserts pack as âplain textâ. > Well, well, but here we come to another problem: if a database is > bulky, it âdoes not wantâ to be loaded as plain text, and it requires > choosing another data format. After this I made a backup with â-Ftâ. > But we can not simply put âtarâ through âiconvâ , so I unarchived it > and made a âfind ./ -exec iconvâ. Well, after all this I could not put > it all back together so that âpg_restoreâ would not find it incorrect. > I had to make a âls | cat | psql databasenameâ. After 15 hours of work > nothing changed! :) > > Also, there is an error in âselect * from table1 where lower(field[1]) > like 'test' â. It looks like this: > > ERROR: invalid byte sequence for encoding "UTF 8" > > HINT: This error can also happen if the byte sequence does not match > the encoding expected by the server, which is controlled by > "client_encoding". > > This error occurs only when we make inquiries with âlower/upperâ for > tables containing massives, and in all other cases it is working properly. > > Have you ever come upon such a mistake? How did you get over it? > > //*****************************************// > > //СÑаÑÑий админиÑÑÑаÑÐ¾Ñ ÐСРУÐТ // > > //ÐÐÐ "ÐнвеÑÑÐапиÑалÐанк" // > > //ÐазоÑез ÐлекÑÐ°Ð½Ð´Ñ ÐÐ»ÐµÐ³Ð¾Ð²Ð¸Ñ // > > //(347)291-37-60, вн. 2021// > > //a.kazorez@investcapitalbank.ru// <mailto:a.kazorez@investcapitalbank.ru> > > //ICQ 400-475-046// > > //*****************************************// >