Previously, when table A had a foreign key pointing to table B, we got
read locks on A and B to read A, a write lock on A and a read lock on
B to update A, and a write lock on B to update B (but this wasn't
applied consistently). Now we get a read lock on A to read A, a write
lock on A to update A, and write locks on A and B to update B. The
difference is small in practice, but clarifying the rules has helped to
catch some bugs.

Perhaps a better solution would be to make all components restartable,
but that's difficult as they may have entered error states.