Zitat von Márcio Merlone <marcio.merlone AT a1.ind DOT br>:
> Em 24-02-2014 12:56, Radosław Korzeniewski escreveu:
>> 2014-02-24 13:16 GMT+01:00 Márcio Merlone <marcio.merlone AT a1.ind DOT br
>> <mailto:marcio.merlone AT a1.ind DOT 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.merlone AT a1.ind DOT br <mailto:marcio.merlone AT a1.ind DOT
>>> 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|