The Tuesday 11 May 2010 20:23:18, Martin Simmons wrote :
> >>>>> 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.
Okay. This point is one where PostgreSQL, from my point of view, is really 
good. Latest versions may still run on old OSes such as SCO Openserver : there 
are not so many external tools or libraries that are required to make Pg run. 
Of course, if you need to do things such as PLPerl, you obviously need Perl. 
But if you only want to use the core, you don't need that many libraries, and 
they don't need to be really up to date. But I admit I don't know how old you 
mean by old OS ;)

> 
> 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.

Ok, so I guess the database isn't that big anyway, if you can use vacuum full 
on it (by the way, you do vacuum full THEN reindex, do you ? because it's 
written in the other order).


Anyway, thanks for answering, I really didn't see such a use case for 
PostgreSQL 7.3 anymore :)

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

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

Reply via email to