Suppose you've filled up most of your memory and that some of that memory contains data that you've written to an NBD-backed device but that hasn't been flushed out yet. The kernel may try to free memory by writing out some of that dirty data. If it were a real remote NBD-backed device, all kinds of fancy logic in the kernel would kick in to get the data written to the network without problems. Because it's actually local, that logic won't do much. Instead, the kernel will successfully deliver the write requests to the Python interpreter's socket. Now the Python script will have to do its own writeback logic while the system is still potentially out of memory. At the very least, this will involve calls to the FoundationDB client library. Since the script is in Python, it's extremley likely that it will also try to allocate some memory to store temporary objects used by the Python code. If that allocation ends up asking the kernel for more memory, then you either deadlock (memory reclaim is waiting for Python, which is in turn waiting for memory) or you trigger an OOM condition. If the latter happens and the Python interpreter gets killed, then you lose data.
