[Citadel Development] Re: master_cleanup() is now the global shutdown/exit function

2023-08-26 Thread IGnatius T Foobar
  
 Geez.  The more I look into the Berkeley DB back end the more fucked up I
find it is.  Disregard the previous comment about the locking subsystem. 
I changed dbenv->open() flags again, this time 
  
 DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN | 
DB_RECOVER
| DB_THREAD 

^^

  
 The documentation says that DB_RECOVER means "run recovery before opening"
but for some reason this combination of flags makes it create __db.00X files
in the data directory, which I think are environment files.  I'm not certain
about that.  But it seems to be more stable now.  I've got a test system (it's
on 'franklin' -- thanks Nurb432) running that I can reliably get to corrupt
itself by interrupting it during a The Dreaded Auto Purger run. 
  
 With any luck we'll be able to make this backend more simple and way more
reliable.  Just in time to deprecate it.  :) 
 


[Citadel Development] Re: master_cleanup() is now the global shutdown/exit function

2023-08-25 Thread IGnatius T Foobar
  
 Some interesting developments here. 
  
 I disabled Berkeley DB's locking subsystem, because Citadel handles locking
and concurrency on its own.  This seems to have fixed the segfault when it
closes the database environment.  I also have not managed to corrupt the 
database
no matter how badly I abuse it, even by forkbombing a test client that writes
to the db, and killing the server process in the middle of that. 
  
 I'd appreciate it if some of y'all could help me test that.  Hit it hard.
 Abuse it.  Preferably with lots of concurrent sessions all performing write
operations.  Let me know how it goes.