>>>>> On Wed, 16 Mar 2005 16:56:27 +0100, Kern Sibbald <[EMAIL PROTECTED]> said:
Kern> On Wednesday 16 March 2005 15:11, Michael Dipper wrote: >> Hi, >> >> On Wed, Mar 16, 2005 at 02:59:12PM +0100, Kern Sibbald wrote: >> > Well, thanks Martin for asking the question, because this was the first >> > thing I was going to check if/when a bug report was filed. >> > >> > To Michael: please turn this off. It is very unlikely to work. I suspect >> > that when you do turn it off, your problems will go away. >> >> Would it work better, if using postgres ? Kern> I think that Martin could point out the pitfalls of this better than I can. Kern> The code was implemented by a user, and I never really thought through the Kern> consequences in applying it. Martin did think it through. Kern> The answer to your question above is, yes, there is a chance that it will work Kern> better because PostgreSQL probably handles TRANSACTIONS better than MySQL. I think the transactions grouping 25000 entries actually make it *more* likely to get duplicates :-) The competing threads will fail to see the other's changes until after the commit, which is a longer time than with the non-transactional approach. The function db_create_filename_record must be *globally* atomic, not just atomic w.r.t. each db connection (which is where the lock currently acts). Ditto db_create_path_record. This applies to all the operations that do SELECT followed by an optional INSERT (e.g. db_create_pool_record) but most of them are related to the configuration which presumably can't be changed by more than one thread simultaneously :-) Kern> However, I would not count on it. In the event one thread creates a new ID, Kern> and a second thread wants to do the same thing, it is very likely that one or Kern> the other of the two threads will completely die with a failed transaction, Kern> or they will both die because of failed transactions, or as apparently is Kern> happening with MySQL, it will create two IDs, which is not the way I designed Kern> the database, and is certain to create problems sometime. Kern> If you use the old code, everything will work correctly. Kern> In any case, I had intended to disable this new directive after Martin pointed Kern> out the flaw, but I forgot to do so. I *will* do so in the next release Kern> though. Better that Bacula runs slower but correctly than running faster and Kern> creating an inconsistent database. >> >> I was quite happy with the "Multiple Connections", since we >> have to backup around 100 servers and usage of bconsole was sometimes >> very "choppy" without multiple connections. Kern> -- Kern> Best regards, Kern> Kern __Martin ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
