On Friday, April 14, 2017 at 12:33:31 AM UTC-7, Nicolò Benigni wrote: > > Thanks, I have solved the problem calling "Model.db.disconnect" at the > start of every job code, it works great. > > I own you a beer! > > Is there maybe a place where I can read about what happen low level that > cause the problem, I always struggle to understand what can happen in this > case, would love to learn! >
PostgreSQL's documentation states it like this: On Unix, forking a process with open libpq connections can lead to unpredictable results because the parent and child processes share the same sockets and operating system resources. For this reason, such usage is not recommended, though doing an exec from the child process to load a new executable is safe. The problem is similar to a thread safety issue. With a thread safety issue, you have two separate threads modifying the same part of memory at the same time. With sharing sockets after fork, you have multiple child processes modifying the same socket/file descriptor at the same time. For example: parent opens socket parent forks child1 parent forks child2 child1 writes "SELECT * FROM" to socket child2 writes "UPDATE table2" to socket child1 writes "table1 WHERE column = 1;" to socket database server interprets query as "SELECT * FROM UPDATE table2 table1 WHERE column = 1;" which is invalid That's a fairly simplified example. In the real world, the database socket protocol is more complex and interleaving child writes is usually going to result in a protocol violation. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
