I ran into an unfortunate experience yesterday and would like to understand if I could have avoided the problem or perhaps there is an opportunity for inclusion of an additional fail-safe within Indigo.
Due to a runaway process, I ran out of disk space on my Indigo server. I noticed tons of repeating log entries with inability to write to Postgres. First step was stopping the Indigo server which seemed to work properly. I then cleaned up disk space. (In retrospect, I probably should have reversed these two steps and let Indigo resume writing). I then restarted the Indigo server, but didn't realize that during the shut down, the Indigo database was corrupted. I was greeted with a screen to reconfigure one of my many plug-ins, which seemed odd, but I figured it was due to a plug-in being updated. I clicked OK. I then received a second plug-in configuration screen and knew something was wrong, so I clicked Cancel. I then received an error that the database was corrupted and was presented with an option to choose another database.
At this point, the damage had already been done. As the SQL logger plugin had loaded successfully, it dropped all the tables for previous devices in my Postgres database. It took a while to figure out what happened: once Indigo realized the database was corrupt, it opened a default empty database and SQL logger did as it's supposed to when switching databases: data clean-up. Thankfully I was able to recover the Indigo database and Postgres database with only a few hours of lost data (otherwise it would have been 3 years of data down the drain!)
It seems to me that perhaps Indigo should check the quality of the database before trying to load any plug-ins at all and advise the user that something is wrong with the previously opened database before opening a default database, assuming of course my assessment of the order of operations and how things broke is accurate.
Matt / Jay - can you please advise whether or not all of this makes sense? Thanks!
Adam