Zitat von Márcio Merlone <marcio.merl...@a1.ind.br>: > Em 24-02-2014 12:56, Radosław Korzeniewski escreveu: >> 2014-02-24 13:16 GMT+01:00 Márcio Merlone <marcio.merl...@a1.ind.br >> <mailto:marcio.merl...@a1.ind.br>>: >> >> >> Em 24-02-2014 07 <tel:24-02-2014%2007>:29, Radosław Korzeniewski >> escreveu: >>> 2014-02-18 13:00 GMT+01:00 Márcio Merlone >>> <marcio.merl...@a1.ind.br <mailto:marcio.merl...@a1.ind.br>>: >>> >>> 2. Fix some utf-8 invalid chars: iconv -c -f UTF-8 -t UTF-8 >>> -o /tmp/bacula_new.sql /tmp/bacula.sql >>> >>> Why do you need this? >>> Bacula (AFAIK) does not use UTF-8 as a database character coding. >> Indeed, but my filesystem is. When restoring catalog dump on the >> new server I got these two messages: >> >> >> ??? >> >> I do not understand. Your file name is /tmp/bacula.sql, it does not >> have UTF8 characters in its name. > I was not referring to the dump file name, but the database records > inside it. My filesystem has lots of UTF-8 encoded chars on file's > names wich gets into catalog records. Some of those (two records) > were the problem. See below, first problem was on line 67185854 of > bacula.sql: > >> psql:/tmp/bacula.sql:67185854: ERROR: invalid byte sequence for >> encoding "UTF8": 0xa2 >> CONTEXT: COPY filename, line 2881 >> psql:/tmp/bacula.sql:69079011: ERROR: invalid byte sequence for >> encoding "UTF8": 0x87 >> CONTEXT: COPY path, line 4771 >> >> >> I think your Bacula database has wrong charset encoding. It should >> be SQL_ASCII not UTF-8, so PostgreSQL should take any 8bit >> character as an input. > root@phobos:~/bin# su - postgres -c "psql bacula -c 'SHOW SERVER_ENCODING'" > server_encoding > ----------------- > SQL_ASCII > (1 row) > > root@phobos:~/bin#
I guess this is a problem with psql used with stdin/stdout on a UTF-8 OS: If at least one of standard input or standard output are a terminal, then psql sets the client encoding to “auto”, which will detect the appropriate client encoding from the locale settings (LC_CTYPE environment variable on Unix systems). If this doesn't work out as expected, the client encoding can be overridden using the environment variable PGCLIENTENCODING. You might try the --file parameter instead of redirecting the dump to psql. The Bacula database should have no other enconding than ASCII, eg. there is no valid UTF-8 in it. On the other hand your dump should include something like "SET client_encoding = 'ASCII'" on top of the file, no? Regards Andreas ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
