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