После использования pg_dump за pg_bouncer путь поиска, по-видимому, изменен, и это затрагивает другие клиенты

#postgresql #pg-dump #pgbouncer

#postgresql #pg-dump #pgbouncer

Вопрос:

Моя сеть выглядит так:

 App       (many connections)   pg_bouncer  (few sessions)   PostgreSql
nodes  -----------------------   nodes   -----------------    nodes
  

Таким образом, pg_bouncer мультиплексирует соединения, создавая у узлов приложения иллюзию, что все они подключены напрямую.

Проблема возникает, когда я запускаю pg_dump: через несколько миллисекунд после завершения дампа все узлы приложения завершаются ошибкой с сообщением «отношение xxxx не существует», хотя таблица или последовательность на самом деле есть. Я почти уверен, что причина в том, что pg_bouncer манипулирует переменной «search_path», так что узлы приложения больше не находят таблицы в моей схеме. Это происходит во время дампа, даже если файл дампа не импортирован и не выполнен.

Обратите внимание, я искал SO и Google, и я видел, что есть много потоков, спрашивающих о search_path в сгенерированном файле, но это не то, о чем я спрашиваю. У меня нет проблем с сгенерированным файлом, моя проблема заключается в сеансе pg_bouncer, который используют другие клиенты, и я ничего об этом не нашел.

Наиболее очевидным обходным путем, вероятно, было бы установить путь поиска вручную в приложении, но внимание, не впадайте в эту ошибку: приложению бесполезно делать это в начале, поскольку ему может быть назначен другой сеанс pg_bouncer при следующей транзакции. И я не могу устанавливать его постоянно.

Следующим наиболее очевидным обходным путем было бы вернуть ему заданное значение сразу после запуска pg_dump, но здесь есть условие гонки, и другие узлы работают достаточно быстро, так что я боюсь, что они все равно потерпят неудачу.

Есть ли способ не позволить pg_dump манипулировать этой переменной или убедиться, что она сбрасывает ее перед выходом?

(Кроме того, я считаю само собой разумеющимся, что причиной этого являются pg_dump и search_path, можете ли вы предложить способ подтвердить это? Все доказательства, которые у меня есть, — это ошибки через несколько миллисекунд и инструкция set search_path в сгенерированном файле, которая при выполнении выдает те же ошибки.)

Спасибо

Комментарии:

1. Вы используете объединение сеансов или транзакций?

2. @LaurenzAlbe объединение транзакций

Ответ №1:

Не подключайте pg_dump через pgbouncer с объединением транзакций. Просто измените номер порта, чтобы он подключался непосредственно к базе данных. pg_dump несовместим с объединением транзакций.

Возможно, вы сможете заставить его работать в любом случае, установив server_reset_query_always = 1

Комментарии:

1. Не уверен, что системные администраторы позволят мне подключиться напрямую. Есть ли какой-либо официальный документ, в котором говорится, что он несовместим? Возможно, было бы полезно обосновать мой запрос. Тем временем я взглянул на server_reset_query_always и server_reset_query, выглядит полезным, я надеюсь, что они согласятся добавить это. Спасибо!

2. Проблема в том, что при объединении транзакций параметры не сбрасываются.

3. Если прямое подключение невозможно, просто добавьте новый пул (1 размер) и подключитесь с его помощью.