Thanks for the idea, Jonathan! I was actually discussing such a fallback watchdog on #postgresql earlier today. Now that I've been having event troubles and it is highlighting atomicity issues with the db/filesystem split, I'm definitely going to implement such a safety net.
I think the problem is slightly different than yours, though. In my case the file have been written in mid-transaction, and I want to delete it if/when the transaction rolls back. If my rollback detector is failing (my bug, I'm sure) I have no db flag to check. The watchdog needs to check the filesystem for dangling files (files with no db reference). This will likely be two phase check (with a big gap) to avoid race conditions, but should be easy enough since file dirs+names are done by database id. If the id is 123456789 it stores to `/files/123/456/789`. The dir splitting should help minimize requirements on filesystem awareness... glad I did that. My bigger problem right now is that the late-firing zombie rollback handler is actually sniping files it shouldn't be! Rollbacks in subsequent/unrelated sessions are sniping files from sessions that ran to commit without issue. Watchdog or not, I need to fix that!! I really wish databases handled hybrid db/filesystem storage better. Any errors in file deletion code are deadly. SQL Server has that nice FILESTREAM object for precisely this situation, but it doesn't seem that others do yet. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
