Совместное использование соединений psycopg2 / libpq через процессы
Согласно документам psycopg2 :
Соединения
libpqне должны использоваться разветвленными процессами , поэтому при использовании модуля, такого какmultiprocessingили метод разворачивания веб-сайтов, например FastCGI, обязательно создавайте соединения после fork.
По ссылке из этого документа:
В Unix разворачивание процесса с открытыми соединениями
libpqможет привести к непредсказуемым результатам, поскольку родительский и дочерний процессы используют одни и те же сокеты и ресурсы операционной системы. По этой причине такое использование не рекомендуется, хотя выполнение exec из дочернего процесса для загрузки нового исполняемого файла является безопасным.
Но, похоже, нет никакой проблемы с процессами forking с открытыми сокетами. Итак, в чем причина предупреждения psycopg2 против разветвления при открытии соединений?
Причина моего вопроса заключается в том, что я видел (предположительно успешный) многопроцессорный подход, который открыл соединение прямо перед разветвлением.
Возможно, безопасно открывать открытые соединения при некоторых ограничениях (например, только один процесс фактически использует соединение и т. Д.)?
- psycopg2 E 'на столе, поле и схеме
- Установка Psycopg2 с помощью pip работает, но не может импортировать модуль на OS X 10.9
- Mac + virtualenv + pip + postgresql = Ошибка: исполняемый файл pg_config не найден
- Как получить список имен столбцов из курсора psycopg2?
- Ошибка установки psycopg2 - Библиотека не загружена: libssl.dylib
One Solution collect form web for “Совместное использование соединений psycopg2 / libpq через процессы”
Ваш довод в основном правильный: нет проблем с открытием соединения перед вилкой, если вы не пытаетесь использовать его более чем в одном процессе.
При этом, я думаю, вы неправильно поняли ссылку «многопроцессорный подход», которую вы предоставили. Фактически это демонстрирует отдельное соединение, открываемое в каждом дочернем элементе. (Перед распаковкой открывается родительское соединение, но оно не используется ни в одном из дочерних элементов.)
Улучшение, данное ответом там (по сравнению с кодом в вопросе), состояло в том, чтобы рефакторировать так, чтобы – вместо того, чтобы открывать новое соединение для каждой задачи в очереди – каждый дочерний процесс открывал одно соединение, а затем делил его на несколько задач выполненных внутри одного и того же дочернего элемента (т. е. соединение передается в качестве аргумента для процессора задач).
Изменить :
В качестве общей практики следует предпочесть создание соединения в процессе, который его использует. В приведенном ответе в родительском контенте перед форкингом создается соединение, а затем используется в дочернем элементе. Это отлично работает, но оставляет каждое дочернее соединение открытым и в родительском, что в лучшем случае является пустой тратой ресурсов, а также потенциальной причиной ошибок.