On Friday, February 22, 2013 3:30:37 PM UTC-8, Michael Granger wrote: > On Feb 22, 2013, at 9:54 AM, Jeremy Evans <[email protected]<javascript:>> > wrote: > > > > FWIW, spawn is fork then exec in unix, not that it matters since I'm > guessing passenger actually does call fork. Try disconnecting before > forking/spawning. > > Jeremy's absolutely correct: database connections which are opened before > forking/spawning absolutely need to be reset afterwards. I am the > maintainer of the 'pg' gem, and I answer about 2 questions like this per > week, always with the same advice. > > Here's how I do it in a little distributed-jobs framework that uses > PostgreSQL+Sequel for queuing: > > > # Called by every child on startup. > def after_fork > reset_file_descriptors > #... > end > > # Reconnect so we aren't using the parent's connection > def reset_file_descriptors > DB.synchronize do |conn| > conn.reset > end > end > IMO, it's better to just call Database#disconnect before fork, instead of trying to reset the connection in each child process after forking, unless your parent process needs the database connections open while it forks children (a fairly uncommon need).
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 http://groups.google.com/group/sequel-talk?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
