>>>>> On Tue, 11 May 2010 18:04:18 +0200, Marc Cousin said:
> 
> The Tuesday 11 May 2010 13:22:49, Martin Simmons wrote :
> > >>>>> On Tue, 11 May 2010 02:22:53 -0400, Kern Sibbald said:
> > > On Tuesday 11 May 2010 01:42:15 Marc Cousin wrote:
> > > > 2010/5/11 Dan Langille <[email protected]>
> > > > 
> > > > > I'm seeing this error during regression testing:
> > > > > 
> > > > > ==>Entering directory
> > > > > /usr/home/dan/src/BaculaRegressionTesting-TRUNK/regress/build/src/cat
> > > > > s postgresql.c:50:78: error: pg_config_manual.h: No such file or
> > > > > directory *** Error code 1
> > > > > 
> > > > > 
> > > > > It happens on PG 7.3 on FreeBSD.
> > > > > 
> > > > > The above should be in the regression testing dashboard, but I don't
> > > > > see it.
> > > > > 
> > > > >    Site: langille_pg73_postgresql_bacula_trunk
> > > > >    Build name: 5.0.2-28Apr10-postgresql-freebsd-8.0-STABLE
> > > > > 
> > > > > Determine Nightly Start Time
> > > > > 
> > > > >    Specified time: 23:00:00 CET
> > > > > 
> > > > > Create new tag: 20100509-2200 - Nightly
> > > > > Submit files (using http)
> > > > > 
> > > > >    Using HTTP submit method
> > > > >    Drop site:http://regress.bacula.org/submit.php?project=bacula
> > > > >    Using HTTP trigger method
> > > > >    Trigger site: http://regress.bacula.org
> > > > >    Dart server triggered...
> > > > >    Submission successful
> > > > > 
> > > > > End nightly-disk Mon May 10 00:48:37 UTC 2010
> > > > 
> > > > Is PostgreSQL 7.3 still supported on bacula ?
> > > 
> > > Not really because if I remember right, 7.4 does not support Batch Insert
> > > mode.  If a user submits a clean patch that makes it work OK, but
> > > otherwise, we are very unlikely to look at the problem.
> > 
> > I was using PostgreSQL 7.3.4 successfully for a while with Batch Insert
> > switched off in Bacula 5.0.1.  The patch below was sufficient to make it
> > compile, i.e. don't include pg_config_manual if NAMEDATALEN is already
> > defined.  This also works withg PostgreSQL 8.4 so I think it is clean.
> > 
> > --- orig/bacula-5.0.1/src/cats/postgresql.c 2010-02-24 15:33:48.000000000
> > +0000 +++ bacula-5.0.1/src/cats/postgresql.c        2010-04-07 
> 17:26:22.000000000
> > +0100 @@ -47,7 +47,9 @@
> >  #ifdef HAVE_POSTGRESQL
> > 
> >  #include "postgres_ext.h"       /* needed for NAMEDATALEN */
> > +#ifndef NAMEDATALEN
> >  #include "pg_config_manual.h"   /* get NAMEDATALEN on version 8.3 or later
> > */ +#endif
> > 
> >  /* -----------------------------------------------------------------------
> >   *
> > 
> > 
> > There were two other problems:
> > 
> > - make_postgresql_tables failed because CREATE TABLE JobHisto (LIKE Job) is
> >   not supported.  There is no clean patch for that, but I just created it
> >   using a copy of the command for the Job table.
> > 
> > - db_add_digest_to_file_record and db_mark_file_record were very slow
> > because the query optimizer failed to use the file_pkey index due to
> > datatype mismatch.  I hacked around that but the patch is not clean.
> > 
> 
> 
> Sorry to insist on this, but 7.3 isn't supported from PostgreSQL point of 
> view. There are several (a lot in fact) bugs that can corrupt your data, 
> bloat 
> your indexes, etc. I know that the database can be rebuilt, with bacula. But 
> if I had to make a choice, I'd rather use a database that doesn't corrupt.
> 
> Can you explain me why you would install a brand new bacula on a database 
> that 
> has been obsoleted a few years ago ?

Three reasons that seemed like good ideas at the time :-)

1) The server was running on an old OS.  I have great confidence that a brand
   new Bacula will work on an old OS with minor adjustments, but I don't have
   the same confidence with a brand new PostgreSQL on an old OS because I'm
   not familiar with the code.

2) It was a transitional stage from old Bacula + old PostgreSQL + old OS to
   brand new everything.  Upgrading Bacula first seemed like the option with
   least impact on stability.

3) Apart from bloat (solved by reindex + vacuum), the old setup had been
   working flawlessly for a long time.  It seemed unlikely that the bugs in
   old PostgreSQL would suddenly start to cause major problems.

__Martin

------------------------------------------------------------------------------

_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to