From: Alan G. <al...@cr...> - 2008-09-09 20:19:38
|
Arno Lehmann wrote: > Hi, > > 09.09.2008 21:07, Alan Garrison wrote: > >> John Drescher wrote: >> >>> On Tue, Sep 9, 2008 at 2:44 PM, Alan Garrison <al...@cr...> <mailto:al...@cr...> wrote: >>> >>> >>>> Skimming a pg_dump of the bacula >>>> database shows nowhere near 162,000 file records. The job completion >>>> email does indicate the proper number of files processed, just not the >>>> Catalog. >>>> >>>> >>>> >>> I assume that a lot of these files have the same name (not including >>> the path)? bacula will only save a filename once in the file table of >>> the catalog >>> > > Might also be related to PostgreSQL's handling of non-ASCII text data, > the character set of the columns in question, and so on. Dan knows > more about this :-) > Well the bacula database is set up for UTF8 instead of SQL_ASCII. Poking around the postgres log I see at the time when a job started: 2008-09-09 09:52:58 EDT ERROR: invalid byte sequence for encoding "UTF8": 0x82 2008-09-09 09:52:58 EDT 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". 2008-09-09 09:52:58 EDT CONTEXT: COPY batch, line 2213 2008-09-09 09:52:58 EDT STATEMENT: COPY batch FROM STDIN I'm guessing something isn't getting properly inserted, though I'm not sure what. That's the only character sequence I see for a large job. > > Without actually verification I believe this means your results don't > "feel" right, which is a bad basis for problem re-creation to be able > to resolve it in the end. > > Now you've got me confused... where does the pg_dump come from, if not > from the PostgreSQL database? > > i.e., If I do a "pg_dump bacula >/tmp/bacula.db" after a Full backup and poke around there's lots less file/path records than I would have expected to see. > Or do you mean that you see the data in the catalog, but can't get it > reported in bat? > > In the latter case, try bconsole, try psql directly, and finally take > special care of the character encoding again. > > Arno > > |