Re: [Bacula-devel] PostgreSQL database diagram

[Kern S. <ke...@si...>]

Hello Dan,

On Fri, 2003-05-16 at 12:36, Dan Langille wrote:
> On 15 May 2003 at 23:59, Kern Sibbald wrote:
> 
> > > > One of the things you will find if you haven't already noticed is
> > > > that I try to use a minimal set of SQL that works for both SQLite
> > > > and MySQL. There is only ONE stupid thing that MySQL did that I
> > > > have not been able to find a single SQL statement that works -- it
> > > > is the concatenation, which if I remember right is || in ANSI SQL,
> > > > but MySQL uses || to mean OR (turkeys!). Their concatenation is
> > > > CONCAT(x, y).
> > > 
> > > It should be easy enough to have one SQL for PostgreSQL and another
> > > for mySQL, even if the differences are minor.  I'll look into the
> > > concatenation issue.
> > 
> > The problem is that it means #ifdef's which I try VERY hard to avoid
> > as it makes the code MUCH harder to read (at least for me).  In one
> > case, the difference is in query.sql a source file that Bacula reads,
> > and there I cannot do #ifdefing.
> 
> What about handling that by ./configure?

Yes, it is quite possible, but a bit painful. One would need
two files and the ability to select between them. Not too hard
to do, but not really a standard ./configure feature.  I'll
think about this a bit.

> 
> > On your other email: I have never tested a file split across three
> > tapes, so there may be a problem, but given that splitting across two
> > tapes has always worked (in all my tests), three tapes should work
> > too. 
> 
> When the files are restored, they are different sizes:
> 
> # ls -l bacula-test-files/one-large-file/largefile2 bacula-
> retore/home/dan/bacula-test-files/one-large-file/largefile2
> -rw-r--r--  1 dan  dan  6253611500 May  9 13:21 bacula-
> retore/home/dan/bacula-test-files/one-large-file/largefile2
> -rw-r--r--  1 dan  dan  6257478656 May  9 13:21 bacula-test-files/one-
> large-file/largefile2

Here are a few possibilities/questions:

1. Your large file has a hole in it, and thus Bacula saved
   and restored the hole making it larger.

2. Was any other process using the file?

3. This file is bigger than 4GB, which means the
   file addresses do not fit into 32 bits. Maybe there is
   some subtle problem here. I have written backup files
   larger than 4GB, but never tested saving/restoring such
   a large file.

4. What options did you use on your Include record?
   e.g. compression, sparse, ...

5. Is there anything special about this file?  I.e.
   what kind of data does it contain?  I'd like to try
   simulating it here but before I run a bunch of tests,
   I'd like to try to make it as similar as possible to
   your file.

6. Do you know if Bacula simply appended additional data,
   or is the file really corrupt?  An interesting test
   would be to truncate the restored file to the same size
   as the original file and then see if the two are the
   same.

Best regards,

Kern