Bug 36240

Summary: Сломан postgis
Product: Sisyphus Reporter: Igor Androsov <blacester>
Component: postgisAssignee: Andrey Cherepanov <cas>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: major    
Priority: P3 CC: aen, cas, ldv, mithraen, nickel, taf
Version: unstable   
Hardware: all   
OS: Linux   

Description Igor Androsov 2019-03-06 16:40:59 MSK
Установлен postgresql10 с расширением postgis которое перестало работать:
Похоже - произошло из-за того что собрано на devel пакете от postgresql11

Вывод при попытке обновить расширение:
ОШИБКА:  загрузить библиотеку "/usr/lib64/pgsql/postgis-2.5.so" не удалось: /usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3

[root@pgsql-srv ~]# rpm -qa |grep postg
postgresql-common-1.0-alt8.noarch
postgis-2.5.1-alt2.x86_64
postgresql10-10.6-alt1.x86_64
postgresql10-python-10.6-alt1.x86_64
postgresql10-tcl-10.6-alt1.x86_64
postgresql10-server-10.6-alt1.x86_64
postgresql10-postgis-2.5.1-alt2.x86_64
postgresql10-contrib-10.6-alt1.x86_64
postgresql10-perl-10.6-alt1.x86_64

[root@pgsql-srv ~]# apt-cache search postgresql |grep post|grep devel
ocaml-postgresql-devel - Development files for ocaml-postgresql
postgresql11-devel - PostgreSQL development header files
postgresql11-devel-static - Development static library for postgresql-devel

Так как расширение жестко завязано на версию postgresql то оно должно собираться на devel пакете версии для которой оно предназначено, и по хорошему для всех существующих в репозитории версий postgresql для которых оно собиралось ранее, иначе ломаются базы в которых оно используется.
Comment 1 Dmitry V. Levin 2019-03-06 16:55:31 MSK
В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее:
verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3

Предлагаю долинковать плагины, после чего включить
%set_verify_elf_method strict
Comment 2 Alexei Takaseev 2019-03-07 10:00:09 MSK
По-идее, postgis надо просто пересобрать под PG-11, поправив в спеке

%define pg_ver 10

на

%define pg_ver 11

По крайней мере у меня получилось собрать, поставить и запустить расширение postgresql11-postgis 2.5.1.
Comment 3 Igor Androsov 2019-03-07 11:14:55 MSK
(В ответ на комментарий №2)
> По-идее, postgis надо просто пересобрать под PG-11, поправив в спеке
> 
> %define pg_ver 10
> 
> на
> 
> %define pg_ver 11
> 
> По крайней мере у меня получилось собрать, поставить и запустить расширение
> postgresql11-postgis 2.5.1.

Тогда каким образом переехать с postgresql10 у которого текущее расширение сломано, на postgresql11? Бакап сделать невозможно, базы бинарно не совместимы.
Comment 4 Alexei Takaseev 2019-03-07 11:16:32 MSK
Откатить из архива последний рабочий postgis и далее по инструкции.
Comment 5 Igor Androsov 2019-03-07 11:46:37 MSK
(В ответ на комментарий №4)
> Откатить из архива последний рабочий postgis и далее по инструкции.

Может все таки более корректным будет:
Собирать для postgres{X} devel пакеты которые провайдят только {names}{X}-devel
Для основной версии провайдить еще имя {names}-devel
Собрать postgis{X} расширение под текущие актуальные версии (9.4-11) опираясь на их {names}{X}-devel пакеты.
У утилит postgis вообще отпилить зависимость на postgres{X}-postgis так как это чисто клиентская часть, которая может быть установлена не там где установлена серверная.
Comment 6 Alexei Takaseev 2019-03-07 12:30:43 MSK
Этап с несколькими -devel уже был. Не прижился по причине сразу же полезших конфликтов с линковкой, потому что помимо вручную прописанных provides rpmbuild генерит массу автоматических. В результате можно вообще не получить сборочную среду из-за конфликтов, либо приложение будет получать не ту версию, какая ей нужна.
Comment 7 Igor Androsov 2019-03-07 14:20:21 MSK
(В ответ на комментарий №6)
> Этап с несколькими -devel уже был. Не прижился по причине сразу же полезших
> конфликтов с линковкой, потому что помимо вручную прописанных provides rpmbuild
> генерит массу автоматических. В результате можно вообще не получить сборочную
> среду из-за конфликтов, либо приложение будет получать не ту версию, какая ей
> нужна.

А можно детальней кого мое предложение потенциально разломает?
Comment 8 Alexei Takaseev 2019-03-07 14:46:46 MSK
Удаление всех libpq кроме самой последней было следствием невозможности собрать части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек, подтягиваемых по автоматически созданным зависимостям set-version. Когда во время прохождения тестов сборка обламывалась на установке debug-пакетов - тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только вернуть, но еще и расширить за счет -devel.

Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть возможность сборки в опцией --with devel. В случае с postgis надо дождаться когда выкатят сборку под PG11. А до этого момента вернуться на последнюю работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По появлению пересобранного postgis провести обновление Hard Upgrade в документации postgis.
Comment 9 Dmitry V. Levin 2019-03-07 14:55:53 MSK
(In reply to comment #1)
> В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее:
> verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> SearchSysCache3
> 
> Предлагаю долинковать плагины, после чего включить
> %set_verify_elf_method strict

В качестве приятного побочного эффекта это изменение заблокирует возможность установить модуль postgis вместе с несовместимой версией libpq.
Comment 10 Igor Androsov 2019-03-07 15:16:47 MSK
(В ответ на комментарий №9)
> (In reply to comment #1)
> > В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее:
> > verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > SearchSysCache3
> > 
> > Предлагаю долинковать плагины, после чего включить
> > %set_verify_elf_method strict
> 
> В качестве приятного побочного эффекта это изменение заблокирует возможность
> установить модуль postgis вместе с несовместимой версией libpq.

Именно расширение, насколько я понимаю, не линкуется на libpq, только клиентские утилиты, которые не сильно важны и могут быть собраны отдельно с любой угодной версией клиентской либы. 

Схожая ругань
"verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
Пример из сборки postgresql9.6
verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: UtfToLocal
verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: error_context_stack
Comment 11 Dmitry V. Levin 2019-03-07 15:19:32 MSK
(In reply to comment #10)
> Схожая ругань
> "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> Пример из сборки postgresql9.6
> verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> UtfToLocal
> verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> error_context_stack

А в каком файле определены эти символы и почему модули самого postgresql не линкуются с этим файлом?
Comment 12 Igor Androsov 2019-03-07 15:32:40 MSK
(В ответ на комментарий №11)
> (In reply to comment #10)
> > Схожая ругань
> > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > Пример из сборки postgresql9.6
> > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > UtfToLocal
> > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > error_context_stack
> 
> А в каком файле определены эти символы и почему модули самого postgresql не
> линкуются с этим файлом?

Ну чисто предположение (пока нет возможности копнуть): динамическая загрузка расширений а символы внутри того кто грузит?
Comment 13 Alexei Takaseev 2019-03-07 15:42:03 MSK
(В ответ на комментарий №11)
> (In reply to comment #10)
> > Схожая ругань
> > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > Пример из сборки postgresql9.6
> > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > UtfToLocal
> > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > error_context_stack
> 
> А в каком файле определены эти символы и почему модули самого postgresql не
> линкуются с этим файлом?

В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как  undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих объектов занимается сам процесс postgresql
Comment 14 Igor Androsov 2019-03-07 16:13:43 MSK
(В ответ на комментарий №8)
> Удаление всех libpq кроме самой последней было следствием невозможности собрать
> части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек,
> подтягиваемых по автоматически созданным зависимостям set-version. Когда во
> время прохождения тестов сборка обламывалась на установке debug-пакетов -
> тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только
> вернуть, но еще и расширить за счет -devel.
> 
> Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть
> возможность сборки в опцией --with devel. В случае с postgis надо дождаться
> когда выкатят сборку под PG11. А до этого момента вернуться на последнюю
> работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По
> появлению пересобранного postgis провести обновление Hard Upgrade в
> документации postgis.

Собрал в хашере по приведенной мной выше идее (собрал 9.3 и 9.6 devel пакеты которые провайдят только версионированные devel), собрал postgis9.3 и postgis9.6 с указанием жестких зависимостей и отпиленными пакетами с клиентской частью, собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь что из-за postgres). Что вижу - собиралось с postgresql11-devel, так как только он провайдит postgresql-devel, в одном из пакетов bacula9 есть зачем-то жестко прописанная зависимость на postgresql10.
Comment 15 Dmitry V. Levin 2019-03-07 16:22:51 MSK
(In reply to comment #13)
> (В ответ на комментарий №11)
> > (In reply to comment #10)
> > > Схожая ругань
> > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > > Пример из сборки postgresql9.6
> > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > > UtfToLocal
> > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > > error_context_stack
> > 
> > А в каком файле определены эти символы и почему модули самого postgresql не
> > линкуются с этим файлом?
> 
> В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как 
> undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих
> объектов занимается сам процесс postgresql

А кто следит за правильным порядком загрузки плагинов, тоже posgresql?
Зачем такой закат солнца вручную?

Похожая схема используется в /usr/lib64/lftp/, но там в конеченом итоге справились с этой задачей нормально, в отличие от postgresql.
Comment 16 Igor Androsov 2019-03-07 16:33:17 MSK
(В ответ на комментарий №14)
> (В ответ на комментарий №8)
> > Удаление всех libpq кроме самой последней было следствием невозможности собрать
> > части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек,
> > подтягиваемых по автоматически созданным зависимостям set-version. Когда во
> > время прохождения тестов сборка обламывалась на установке debug-пакетов -
> > тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только
> > вернуть, но еще и расширить за счет -devel.
> > 
> > Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть
> > возможность сборки в опцией --with devel. В случае с postgis надо дождаться
> > когда выкатят сборку под PG11. А до этого момента вернуться на последнюю
> > работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По
> > появлению пересобранного postgis провести обновление Hard Upgrade в
> > документации postgis.
> 
> Собрал в хашере по приведенной мной выше идее (собрал 9.3 и 9.6 devel пакеты
> которые провайдят только версионированные devel), собрал postgis9.3 и
> postgis9.6 с указанием жестких зависимостей и отпиленными пакетами с клиентской
> частью, собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь
> что из-за postgres). Что вижу - собиралось с postgresql11-devel, так как только
> он провайдит postgresql-devel, в одном из пакетов bacula9 есть зачем-то жестко
> прописанная зависимость на postgresql10.

Ошибся при наборе - не 9.3 а 9.4
Comment 17 Николай Костригин 2019-03-07 16:46:23 MSK
(В ответ на комментарий №14)
> собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь
> что из-за postgres)

начиная с 9.0.6-alt4 должна собираться
Comment 18 Alexei Takaseev 2019-03-08 17:08:27 MSK
(In reply to comment #15)
> (In reply to comment #13)
> > (В ответ на комментарий №11)
> > > (In reply to comment #10)
> > > > Схожая ругань
> > > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > > > Пример из сборки postgresql9.6
> > > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > > > UtfToLocal
> > > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > > > error_context_stack
> > > 
> > > А в каком файле определены эти символы и почему модули самого postgresql не
> > > линкуются с этим файлом?
> > 
> > В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как 
> > undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих
> > объектов занимается сам процесс postgresql
> 
> А кто следит за правильным порядком загрузки плагинов, тоже posgresql?

Да.

> Зачем такой закат солнца вручную?

Возможно, разработчики посчитали это удобным.

> Похожая схема используется в /usr/lib64/lftp/, но там в конеченом итоге
> справились с этой задачей нормально, в отличие от postgresql.

Вообще-то postgres и так с этим справляется успешно. С идущими в комплекте расширениями проблем нет.
Comment 19 Igor Androsov 2019-03-08 21:04:33 MSK
(В ответ на комментарий №13)
> (В ответ на комментарий №11)
> > (In reply to comment #10)
> > > Схожая ругань
> > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > > Пример из сборки postgresql9.6
> > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > > UtfToLocal
> > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > > error_context_stack
> > 
> > А в каком файле определены эти символы и почему модули самого postgresql не
> > линкуются с этим файлом?
> 
> В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как 
> undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих
> объектов занимается сам процесс postgresql

Все таки настою на своем варианте ответа на вопрос Дмитрия.
Процесс postgresql динамически грузит нужные расширения.
Большая часть символов помеченных как undefined находятся в самом postgres (я думаю что вообще все, однако я это не проверял и утверждать не буду).
Насколько я вижу расширения не имеют связей между собой поэтому тут нет значения в каком порядке они грузятся (да и грузится будут только те которые подключены в базе).

Все стандартные расширения билдятся вместе с postgres, и с ними проблем нет.
Postgis же - отдельное расширение, для сборки которого нужна серверная часть devel.

Исходя из этого и понимая что вероятность появления devel пакетов крайне низка, есть еще вариант как сделать все таки по человечески, а не в варианте я вам тут поломал, а вы теперь сами разбирайтесь: 
Собирать postgis вместе с postgres, как будто он часть стандартных расширений.
Comment 20 Repository Robot 2019-03-21 18:31:14 MSK
postgis-2.5.2-alt1 -> sisyphus:

Tue Mar 19 2019 Andrey Cherepanov <cas@altlinux> 2.5.2-alt1
- New version.
- Require postgresql11 (ALT #36240).