On Monday 21 December 2009 09:39:43 Eric Bollengier wrote:
> Le dimanche 20 décembre 2009 21:34:51, Kern Sibbald a écrit :
> > On Sunday 20 December 2009 20:59:05 Eric Bollengier wrote:
> > > Le dimanche 20 décembre 2009 19:26:43, Eric Bollengier a écrit :
> > > > Postgres gives an API call to determine if the client is thread-safe
> > > > or not, perhaps MySQL do the same (i will check).
> > >
> > > MySQL API has mysql_thread_safe() (found on 3.1/4.0 manual)
> > > PostgreSQL has PQisthreadsafe() (but only for >= 8.2)
> > > SQLite3 has sqlite3_threadsafe()
> > >
> > > Do you think that possible to test the result of this function in the
> > > ./configure ? (I would say yes, and i can look tomorrow)
> >
> > Yes, it is possible, but a bit ugly to do.
>
> The ./configure output contains many hacks like that.
>
> PostgreSQL has a nice pg_config prog that should help to avoid ugly testing
> to find options like includedir, libdir, binary path, etc...
>
> $ pg_config --includedir
> /usr/include
>
> $ pg_config --libdir
> /usr/lib
>
> I think that we can have the same kind of prog to get config.out and
> configure option available for support.

Yes, we are using such config programs more and more in ./configure, and this 
is one we can probably add.  The problem is that not all users have them 
installed -- all these little xxx_config programs should be a required part 
of the base system.


>
> > > We can use the old way as workaround for postgresql 8.0, and 8.1
> >
> > What I suggest is I change the current code in configure so that it
> >  complains but it does not disable batch insert.  Then we add new code
> > that uses the API calls and if batch insert is turned on when we try to
> > open a connection and thread safe is not enabled, we M_ABORT Bacula.
>
> I will add the code in this way.
>
> > For old postgres versions, we warn the user in the documentation.

As far as I can tell, the problem I was seeing was localized to our current 
development version.  I have now fixed it.  Until we find a better method, I 
am planning to leave the current ./configure code in place, but I think we 
should go ahead with implementing the API calls either in the current 
development version or in the next one as time permits.

Kern

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to