Добрый вечер.

Для получения доступа к данным Active Directory из PostgreSQL, установил расширение multicorn https://github.com/Segfault-Inc/Multicorn которое позволяет выполнять программы, написанные на питоне. Предлагается готовый скрипт, общающийся с python-модулем ldap3 https://github.com/Segfault-Inc/Multicorn/blob/master/python/multicorn/ldapfdw.py

В общем, все работает, данные с домена получаю, довольно быстро (20 мс), но это справедливо, если запрос не первый в установленной сессии подключения.
Первоначально, когда я соединяюсь с СУБД клиентом psql или EMC SQL Manager и пробую выполнить запрос
SELECT displayname
FROM ad
WHERE samaccountname='логин1'
результат появляется через 6-7 секунд.
В дальнейшем тот же запрос для 'логин2', или вообще другой запрос к любой маппированной таблице через fdw_ldap длится 20 мс (т.е. дело ни в каком не кешировании).
Судя по всему долго стартует само расширение (либо долго загружается программа на питоне в СУБД. Скорее причина в этом, т.к. сам multicorn написан на Си).
Если отключиться от СУБД и тут же подключиться снова - опять будет долгий старт первого запроса.
Одно радует: если подключиться из приложения к БД и вызвать хранимку, которая берет данные из таблиц ldap_fdw, первый запрос длится тоже долго - 6-7 сек. Но, даже если вызвать Dispose у контекста при использовании ORM (EF), следующий запрос все равно исполнится мгновенно (приложение ASP.NET). Скорее всего подключение не гасится в приложении на самом деле, либо откладывается на какое-то время, чтобы кода приложению понадобится в следующий раз обратиться к БД, не было больших накладных расходов.
Pgbouncer не используется.
Кроме как костылями победить, ничего в голову не приходит (при запуске приложения оно должно первым делом обратиться к доменной таблице). Это лучше чем когда пользователь делает HTTP-запрос к приложению и потом ждет несколько секунд пока загрузится расширение. Однако это все полумеры, т.к. приложение может уснуть, и все сначала. Плюс ко всему активно используются реплики, на которых также читаются таблицы ldap через ldap_fdw и само приложение опубликовано на двух серверах приложений.
Используется балансировщик haproxy. Придется в приложении указывать адреса всех СУБД, чтобы оно сделала холостые запросы к каждой из них, т.к. я могу сказать балансировщику, что хочу обратиться на реплику, а дальше он сам решит с какой он меня соединит, и запомнит это для моей машины. Т.е. не исключена ситуация, при которой балансировщик оба сервера приложений
направит только на одну реплику из трех при старте приложения, а в дальнейшем решит переключить на другую реплику, на которой расширение multicorn с программой на python еще не запущено.
Читал документацию по postgresql есть параметр shared_preload_libraries, при котором необходимо чтобы исходный код на Си загружаемого расширения зарегистрировал имя, которое следует задатьв качестве значения указанному параметру. Не совсем понятно, и то ли это на самом деле.
Может кто-то сталкивался с подобным - с долгим запуском внутри СУБД какого-то стороннего модуля, и есть решение с быстрым стартом, например, при запуске СУБД, чтобы расширение было загружено и сразу готово к работе при подключении нового клиента?
Понимаю, что колхоз, но мне необходимо читать данные из домена в СУБД напрямую. И те решения (практически все), которые я просмотрел - либо очень старые (нерабочие для PG 11), либо тоже со своими косяками, в т.ч. от CDATA (техподдержка не во всем смогла помочь). Решение multicorn также не заводилось без напильника, но оно оказалось наиболее приемлемым.

Maxim Boguk,

Можно подробнее про "посмотреть как он что загружает"?
Я просмотрел /usr/local/pgsql/share/extension/multicorn--1.4.0.sql
-- create wrapper with validator and handler
CREATE OR REPLACE FUNCTION multicorn_validator (text[], oid)
RETURNS bool
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;

CREATE OR REPLACE FUNCTION multicorn_handler ()
RETURNS fdw_handler
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;

CREATE FOREIGN DATA WRAPPER multicorn
VALIDATOR multicorn_validator HANDLER multicorn_handler;

и /usr/local/pgsql/share/extension/multicorn.control
comment = 'Multicorn Python bindings for Postgres 9.2.* Foreign Data Wrapper'
default_version = '1.4.0'
module_pathname = '$libdir/multicorn'
relocatable = true

Ничего полезного не нашел.
Пробовал команду load 'multicorn'. Выпоняется без ошибок. Но толку нет.
Пробовал прописывать значение 'multicorn' и во shared_preload_libraries и в session_preload_libraries. Тоже не помогает.

Судя по всему значение верное, т.к. если указать 'abc', то возникает ошибка при LOAD и ошибка запуска сервера, если 'abc' указать в postgresql.conf