Возникла необходимость поднять на Gentoo PostgreSQL-сервер для 1С-ки. Как всем известно одинэсовцы являются знаменитыми костылестроителями и в данном случае СУБД PostgreSQL не обошли стороной, тем что вмешиваются в ее исходный код.
Почему Gentoo? Потому что данный дистр можно заточить для решения узко определенной задачи, со всеми преимуществами оптимизации USE-флагов, в отличие от бинарных дистров, в которые много вшивается «про запас», а сборка собственных пакетов означает отказ от пакетных менеджеров (может и не так, не знаток этого вопроса), что сильно ухудшает поддержание инсталляции в актуальном состоянии. Ну и к тому же, на то он и гентушник раз любит сам готовить.
Поиски в интернете не принесли желаемого результата, а именно не нашлось ebuild-а, для такой задачи, хотя упоминания имеются, на неком ростовском сервере, то некто выкладывал на форуме http://linuxforum.ru (может плохо искал), то изобретали костыли с использованием rpm2cpio над пропатченными сырцами, а то и вовсе редхатовскими бинарниками плюс ко всему еще ручное редактирование стартовых скриптов, кроме того на том же ftp-сервере лежит уже готовый
ebuild, но как показывает вскрытие, он лишь копирует в систему кем-то уже собранные пакеты, но сим не есть путь джедая генту. А приемлемый вариант — без левых зависимостей, установка в директории стандартные для этой системы и чтобы пакетный менеджер «знал» о нашей инсталляции и считал ее родной, учитывая make.conf и USE-флаги. Как очевидно нужен именно ebuild.
Имеется хорошая компания http://etersoft.ru, которая делится своими наработками. У них берем патчи адаптирующие PostgreSQL для 1С-ки — postgresql-8.4eter-8.4.4-alt1.1.src.rpm, т.к. у самих 1С-цев на сайте патчи только для версии 8.4.1 (опять-таки может плохо искал, а может они и подходят для нашей версии). Кроме того, етерсофтовцы опять таки патчат некоторые наработки одинэсевцев, исправляя их баги.
Но как показала попытка наложения этих патчей и етерсофтовцы с ними немного намудрили. Пришлось брать напильник, молоток, зубило, кувалду и прочую атрибутику системного администратора.
Итак, наш квест будет заключаться в следующем:
- получение патчей с сайта etersoft.ru
- создание локального оверлея
- наложение гентушных патчей на оригинальные исходники
- наложение етерсофтных патчей поверх гентушных
- снятие diff-а с изготовленных исходников в целях получения единого патча
- оформление патча для кормления epatch'а
- оформление ebuild'а
- тюнинг системы
- напутствия жаждущим
Где мы находимся
В качестве версии СУБД будем использовать версию 8.4.4, хотя сейчас уже 1с-цы выложили патчи для 9-й версии, думаю не будет сложно и их адаптировать по аналогии.
Ранее установленная ОС Gentoo x64 на домашней машине [4G 1333, 1Tb] (самопальное ядро Linux localhost 2.6.36-gentoo-r5 #1 SMP Sun Dec 26 21:57:53 YEKT 2010 x86_64 Intel® Core(TM) i3 CPU 530 @ 2.93GHz GenuineIntel GNU/Linux), которая содержит очень много лишнего для боевого сервера узко-направленного значения, но это нам не помешает, а скорее будет проще не отвлекаться на шлифовку ядра, если таковое требуется, о чем мне не ведомо.
Что мы имеем
Для начала обновим порты, это уж кто как предпочитает, я делаю так:
# eix-sync
Посмотрим что нам предлагают в портежах:
eix postgresql-server
[D] dev-db/postgresql-server
Available versions:
(8.1) 8.1.21-r1 ~8.1.22
(8.2) 8.2.17-r1 ~8.2.18
(8.3) 8.3.11-r1 ~8.3.12
(8.4) 8.4.4-r1!t ~8.4.5!t
(9.0) ~9.0.0!t ~9.0.1!t
Как видно последняя размаскированная (а значит стабильная) версия postgresql-а — 8.4.4-r1, то что нам нужно.
Качаем патчи
Как было сказано качаем патчи PostgreSQL (одним архивом с исходниками) отсюда postgresql-8.4eter-8.4.4-alt1.1.src.rpm. Открываем архив кому как угодно, я пользуюсь Gnome — у него имеется менеджер архивов и вытаскиваем оттуда следующие файлы:
- 1c_FULL_84-0.19.2.patch — оригинальный 1с-ский патч, добавляет три новых модуля fulleq, fasttrun, mchar и еще массу телодвижений
- 1cfix_etersoft.patch — данный патч фиксит 1с-ский патч
- applock-1c-8.4.1.patch — добавляет необходимые типы блокировок
- eter-rename-libpq.patch — переименовывает библиотеку (единственное, что мне пришло в голову зачем это сделано, так это чтобы как то отметиться в системе, — вместо стандартного названия libpq, делает название libpq-8.4eter, мне это показалось саморекламой, поэтому данный патч не был использован, к тому же при сборке PostgreSQL все же хочет файл libpq, так что ребята недостарались)
- postgres_datalen.patch — что-то меняет для успешной инициализации кластера PostgreSQL (initdb)
- postgresql-1c-8.4.patch — рихтует Makefile для сборки модулей написанных 1с-цами — fulleq, fasttrun, mchar, плюс рихтует конфиг для PostgreSQL
- postgresql.conf.sample.patch — как видно из названия, также рихтует конфиг (честно говоря не понимаю для чего это сделано, ребята полагают, что PostgreSQL будут ставить полные нули которые не осилят чтения документации?)
- postgresql-no_transaction_blocks.patch — этот и следующие два патча, по мелочам вносят правки
- postgresql-perl-rpath.patch
- postgresql-tmp_table_cleanup.patch
- rpm-pgsql.patch — снова непонятное действо — меняет директорию размещения кластера PostgreSQL с /var/lib/postgresql, на /var/lib/pgsql
- timestamp.c.diff — корректировки насчет пустого поля времени — по аналогии с MSSQL, устанавливает в качестве даты значение 1900-01-01 по умолчанию для полей даты таблицы — могу ошибаться, но где-то встречал такое описание (патч в несколько строк там все понятно).
Сохраним патчи сюда
mkdir -p /tmp/postgresql/patches
Локальный оверлей
Для интеграции в существующее дерево портежей плодов наших манипуляций сделаем локальный оверлей (почитать можно здесь http://ru.gentoo-wiki.com/wiki/Portage_Overlay):
echo 'PORTDIR_OVERLAY="/usr/local/portage"' >> /etc/make.conf
install -d /usr/local/portage
У кого будут ругания на оверлей, почитать man make.conf и гугл — у меня не было косяков, но может быть конфликт с другими параметрами в нем, на предмет очередности их объявления.
По аналогии с родной структурой дерева портежей создаем структуру директорий для локального:
mkdir -p /usr/local/portage/dev-db/postgresql-server
Копируем исходный ebuild, который будем патчить:
cp /usr/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r1.ebuild \
/usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild
Стоит обратить внимание что исходный ebuild имеет версию обновления r1, нам нужно чтобы не совпадало с ней, поэтому свой ebuild называем r3 (r2 появился у меня после очередного eix-sync), — надо выбирать именование так чтобы не пересекалось с имеющимися ebuild'ами, возможно можно как-то еще, но по правилам именования нужно соблюдать определенные требования.
Также при сборке PostgreSQL понадобятся патчи подготовленные командой Gentoo, вероятно как-то можно использовать их из системного дерева портежей, но пока не знаю как, так что делаем:
cp -R /usr/portage/dev-db/postgresql-server/files \
/usr/local/portage/dev-db/postgresql-server
Хотя реально оттуда требуется всего лишь два файла:
- /usr/portage/dev-db/postgresql-server/files/postgresql-8.4-common.patch
- /usr/portage/dev-db/postgresql-server/files/postgresql-8.4-server.patch
Приготовление исходников
Использовать исходники PostgreSQL от команды etersoft'а не будем (как-то в душу запали только их патчи), а возьмем те что тянет emerge из интернета для оригинального PostgreSQL.
Загружаем исходники:
emerge -fv dev-db/postgresql-server
Сделаем рабочую директорию и распакуем туда сырцы:
mkdir -p /tmp/postgresql/orig && cd /tmp/postgresql/orig
tar xjf /usr/portage/distfiles/postgresql-8.4.4-tar.bz2
Идем туда и накладываем гентушные патчи:
cd /tmp/postgresql/orig/postgresql-8.4.4
patch -p0 -g0 -E < /usr/local/portage/dev-db/postgresql-server/files/postgresql-8.4-common.patch
patch -p1 -g0 -E < /usr/local/portage/dev-db/postgresql-server/files/postgresql-8.4-server.patch
С ключами у них для одного патча применяем -p0 для другого -p1, по-крайней мере у меня так получилось. Хотя можно применять просто команду: patch -pX < , но анализ лог-файлов показал, что epatch использует такую хитрую комбинацию ключей. Теперь считаем что у нас получились эталонные исходники, на которые будет ebuild накладывать патчи для 1с-ки при запуске emerge.
Подготовим площадку для дальнейших экзекуций:
mkdir -p /tmp/postgresql/patch
cp -R /tmp/postgresql/orig/postgresql-8.4.4 /tmp/postgresql/patch
Теперь нужно внимательно изучить файл postgresql-8.4eter.spec, поставляемый в postgresql-8.4eter-8.4.4-alt1.1.src.rpm, чтобы определить в каком порядке накладываются патчи, вообщем имеется такая секция описывающая порядок и уровень -pX, с которым они применяются:
# Patch1: rpm-pgsql.patch
%patch1 -p2
# Patch4: postgresql-test.patch
# now test is by C program.
# %patch4 -p1
# Patch6: postgresql-perl-rpath.patch
%patch6 -p2
# Patch7: 1c_FULL_83-0.19.patch
%patch7 -p2
# Patch8: postgresql-1c-8.4.patch
%patch8 -p2
# Patch9: applock-1c-8.3.1.patch
%patch9 -p0
# Patch10: timestamp.c.diff
%patch10 -p2
# Patch11: postgresql.conf.sample.patch
%patch11 -p2
# Patch12: pg_hba.conf.sample.patch
# already included in postgresql-1c-8.3.patch
# %patch12 -p1
# Patch13: postgres_datalen.patch
%patch13 -p2
# Etersoft's fix for 1c patches
# Patch15: 1cfix_etersoft.patch
%patch15 -p2
# Etersoft rename libpq
%patch50 -p2
#Patch51: postgresql-tmp_table_cleanup.patch
%patch51 -p1
#Patch52: postgres-no_transaction_blocks.patch
%patch52 -p2
А как же в Gentoo?
Последив как работает команда ebuild при сборке пакетов (немного есть здесь http://www.gentoo.org/doc/ru/handbook/handbook), выяснил что выполняются по шагам следующие действия:
- ebuild /path/to/ebuild fetch
- ebuild /path/to/ebuild unpack
- ebuild /path/to/ebuild prepare
- ebuild /path/to/ebuild compile
- ebuild /path/to/ebuild install
- ebuild /path/to/ebuild qmerge
- ebuild /path/to/ebuild clean
Распаковка исходников производится в каталог: /var/tmp/portage/dev-db/postgresql-server/work/postgresql-8.4.4 и он делается текущим, затем при выполнении команды prepare, накладываются патчи и выполняется ./configure, т.е. команда patch вызывается с уровнем -p0 (хотя и это меняется редактированием ebuild-файла), вот это и нужно поправить в патчах. Вообщем как удалось расковырять патчи ложатся в следующем порядке, хотя для некоторых он не важен (не спешим патчевать, а читаем дальше):
cd /tmp/patch/postgresql
# сделаем симлинк
ln -s postgresql-8.4.4 postgresql
patch -p2 < postgreslq-perl-rpath.patch
patch -p2 < 1c_FULL_83-0.19.patch
patch -p0 < applock-1c-8.3.1.patch
patch -p2 < timestamp.c.diff
patch -p2 < postgresql.conf.sample.patch
patch -p2 < postgres_datalen.patch
patch -p2 < 1cfix_etersoft.patch
patch -p1 < postgresql-tmp_table_cleanup.patch
patch -p2 < postgres-no_transaction_blocks.patch
Как видно, были пропущены файлы prm-pgsql.patch и eter-rename-libpq.patch по причине описанной ранее. Также patch споткнется на файле postgresql-1c-8.4.patch, — он выполняет редактирование файла postgresql/contrib/Makefile, на предмет добавления в собираемые модули fulleq, mchar и fasttrun — т.к. гентушные патчи тоже наводят там небольшой порядок, то возникает конфликт. Поэтому данный патч можно не применять, а дописать модули вручную (тру-гении смогут и патч отрихтовать). Также этот патч по мелочи шлифует pg_hba.conf.sample и postgresql.conf.sample, т.е. конфигурационные файлы, на попсовые настройки — никто же не собирается использовать дефолтные, поэтому можно смело забить. И чтобы было все как с остальными, то содержимое файла postgresql-1c-8.4.patch можно заменить на:
--- ../contrib/Makefile 2011-01-06 15:30:50.670856014 +0500
+++ ../contrib/Makefile 2011-01-06 16:00:39.664856014 +0500
@@ -36,7 +36,10 @@
spi \
tablefunc \
tsearch2 \
- test_parser
+ test_parser \
+ fasttrun \
+ fulleq \
+ mchar
ifeq ($(with_openssl),yes)
WANTED_DIRS += sslinfo
Также файл applock-1c-8.4.1.patch в голом виде так и не смогла переварить команда patch. Исследование содержимого показало, что пути к файлам, предназначенные для изменений начинаются следующим образом, например первая строка того же файла содержит:
diff -c -r -N ..\postgresql-8.4.0/doc/src/sgml/ref/lock.sgml ./doc/src/sgml/ref/lock.sgml
где видно, что путь к файлу начинается с обратного слэша ..\, есть предположение что данный патч писался под ОС Windows, однако дальнейшие слэши все же правильные, к тому же тут указывается версия PostgreSQL 8.4.0, что есть не страшно, я делал так:
cd /tmp/postgresql/patches
cat applock-1c-8.4.1.patch | sed 's!\.\.\/postgresql\-8\.4\.0!\.\./postgresql\-8\.4\.0!' > \
applock-1c-8.4.1.patch-fix && mv applock-1c-8.4.1.patch-fix applock-1c-8.4.1.patch
т.е. заменяем неправильный слэш.
И делаем симлинки:
cd /tmp/postgresql/patch
ln -s postgresql-8.4.4 postgresql-8.4.0
После манипуляций с патчами можно еще раз прогнать «патчевание» (или все сначала, предварительно сделав rm -rf /tmp/postgresql/patch/postgresql-8.4.4 && cp -R /tmp/postgresql/orig/postgresql-8.4.4 /tmp/postgresql/patch/), т.к у меня все патчи наложились далеко не с первого раза, то процедуру наложения лучше записать в bash-скриптик.
В итоге в директории /tmp/postgresql/ имеем следующую структуру:
/tmp/postgresql/
|
+- orig (оригинальный PostgreSQL + Gentoo-патчи)
| |
| +- postgresql-8.4.4
|
+- patch (копия orig/postgresql-8.4.4 + патчи 1С/etersoft)
| |
| +- postgresql
| +- postgresql-8.4.0
| +- postgresql-8.4.4
|
+- patches
|
+- список файлов-патчей
Наложение патчей от 1c/etersoft
Собственно процедура наложения выглядит таким образом (после всех манипуляций, исправлений и рихтований):
cd /tmp/postgresql/patch/postgres
patch -p2 ../../patches/postgreslq-perl-rpath.patch
patch -p2 ../../patches/1c_FULL_83-0.19.patch
patch -p2 ../../applock-1c-8.3.1.patch
patch -p2 ../../timestamp.c.diff
patch -p0 ../../postgresql-1c-8.4.patch
# Данный патч немного глюкавит, но как очевидно,
# он делает то что будет переделано - тюнинг конфиг-файла
# patch -p2 ../../postgresql.conf.sample.patch
patch -p2 ../../postgres_datalen.patch
patch -p2 ../../1cfix_etersoft.patch
patch -p1 ../../postgresql-tmp_table_cleanup.patch
patch -p2 ../../postgres-no_transaction_blocks.patch
Получение итогового патча
Возня с исходниками практически закончена, осталось только сделать свой патч и прописать все это дело в ebuild-файле:
cd /tmp/postgresql/patch/
ln -s /tmp/postgresql/orig/postgresql-8.4.4 postgresql-8.4.4.orig
cd /tmp/postgresql/patch/postgresql-8.4.4
diff -urdN ../postgresql-8.4.4.orig ../postgresql-8.4.4 > ../postgresql-8.4-1c8all.patch
# ../postgresql-8.4-1c8all.patch - это наш патч, который можно отослать другу-гентушнику
# Копируем в директорию к остальным патчам
cp /tmp/portage/patch/postgresql-8.4-1c8all.patch /usr/local/dev-db/postgresql-server/files
Свой патч мы делаем, чтобы получить разницу между исходным деревом PostgreSQL и патченным, чтобы эта разница (патч) уместилась в одном файле — так менее геморно будет с ebuild-ом возиться.
Шлифуем ebuild-файл
Открываем в любимом редакторе ранее сделанную копию ebuild-файла:
mcedit /usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild
и вносим правки.
В строке 3 можно поменять (не уверен, что не нужно хотя работает и без правки):
# $Header: /var/cvsroot/gentoo-x86/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild,v 1.6 2010/08/11 19:27:10 josejx Exp $
— ревизию ebuild-файла
Далее в строке можно поменять
DESCRIPTION="PostgreSQL server with patchset from 1C company. Prepared by ME"
Менять обязательно:
IUSE="1c8 pg_legacytimestamp doc perl python selinux tcl uuid xml nls kernel_linux ${IUSE_LINGUAS}"
— добавили ключик «1c8»
Ищем функцию src_prepare() и после слов epatch ...-common.patch ...-server.patch пишем свое:
if use 1c8; then
epatch "${FILESDIR}/postgresql-${SLOT}-1c8all.patch"
fi
Создание цифровой подписи для ebuild-файла
cd /usr/local/portage/dev-db/postgresql-server
ebuild postgresql-server-8.4.4-r3.ebuild digest
# Если все в порядке, то получим, если нет - то читаем вывод и в маны и гугл
>>> Creating Manifest for /usr/local/portage/dev-db/postgresql-server
Подготовка к установке
Небольшой тюнинг:
# Архитектура нашего ПК (в данный момент уже является стабильным для x86 и amd64) поэтому можно и не делать
echo '=dev-db/postgresql-server-8.4.4-r3 amd64' >> /etc/portage/package.keywords
# Маскируем версии старше нашей, чтобы по-умолчанию ставилась наша
echo '>dev-db/postgresql-server-8.4.4-r3' >> /etc/portage/package.mask
# Указываем USE-флаг ради которого все затевалось
echo '=dev-db/postgresql-server-8.4.4-r3 1c8' >> /etc/portage/package.use
Установка PostgreSQL с патчами от 1C — gentoo-way
Перед тем как выполнять установку проверим, что нам скажет emerge:
emerge -pv postgresql-server
[ebuild R ] dev-db/postgresql-server-8.4.4-r3 USE="'''1c8''' nls perl python -doc -pg_legacytimestamp \
(-selinux) -tcl -uuid -xml" LINGUAS="ru -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -sk -sl \
-sv -tr -zh_CN -zh_TW" 0 kB [?=>1]
Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage
[?] indicates that the source repository could not be determined
Как видим emerge по-умолчанию выбирает нашу сборку. Emerge увидел два дерева портежей — системный и наш локальный, среди флагов USE появился флаг 1c8.
Для 1с-сборки PostgreSQL, помимо самого флага 1с8, флаги tcl, perl, python, selinux не являются обязательными, т.к. вроде бы являются биндингами к соответсвующим ЯП, насчет остальных не уверен.
Стоит обратить внимание на USE-флаг pg_legacytimestamp. Когда он был отключенным, то в заливаемой из бэкапа базе данных (с рабочего кластера) дата и время всех документов была установлена в 2000.01.01 00:00:00, хотя если загружать из dt-файла, такого может и не быть. Когда устанавливаем этот флаг, то emerge также хочет установить порт dev-db/postgresql-base-8.4.4-r2, также с установленным этим флагом — не сопротивляться и установить также и его (можно также редактированием postgresql-server-8.4.4-r3 выпилить его из зависимостей, чтобы сделать уж совсем красивый ebuild, т.к. по postgresql-base ставит из тех же самых исходников, тот же самый сервер с небольшими отличиями).
А теперь ставим:
emerge -av postgresql-server
Если внимательно посмотреть, то заметим, что после распаковки исходников, происходит наложение патчей по порядку:
postgresql-8.4-common.patch
postgresql-8.4-server.patch
postgresql-8.4-1c8all.patch
А после того как СУБД будет установлена в директорию (можно увидеть при работе процедуры копирования файлов при установке) /usr/lib64/postgresql-8.4/lib64 помимо идущих в комплекте файлов модулей, будут лежать 1с-ские модули: fasttrun.so, fulleq.so и mchar.so.
Послеустановочный тюнинг
В интернете много сообщений на тему руганья 1с-ки: ERROR: Invalid value for parameter “lc_messages”:”en_US”. Для Gentoo смотрим:
cat /etc/locale.gen | grep -v "#"
en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
По рекомендации из того же файла проверяем:
cat /usr/share/i18n/SUPPORTED | grep "en_US"
# en_US.UTF-8 UTF-8
# en_US ISO-8859-1
и добавляем локаль:
echo 'en_US.ISO-8859-1' >> /etc/locale.gen
и обновляем систему:
locale-gen
env-update && source /etc/profile
Может случиться что это не совсем поможет..., — читаем дальше
Файл /etc/conf.d/postgresql-8.4
Смотрим файл на предмет переменных, кластер баз данных по-умолчанию находится по адресу PGDATA, можно поменять как угодно, у меня было так:
PGDATA=/var/lib/postgresql/8.4
поменял на (это на любителя):
PGDATA=/var/lib/postgresql
Установим:
PG_INITDB_OPTS="--local=ru_RU.UTF-8"
# Это чтобы PostgreSQL начал слушать на всех адресах, можно указать конкретный
PGOPTS="-h 0.0.0.0"
PG_EXTRA_ENV="LC_ALL=\"ru_RU.UTF-8\""
Но и в таком случае тема «lc_messages» может себя не исчерпать, то делаем вмешательство в скрипт запуска/останова (/etc/init.d/postgresql-8.4) — где-нибудь в начале файла, перед описанием функций, добавляем:
export LC_ALL=ru_RU.UTF-8
На старт...
Если внимательно смотреть лог установки СУБД, то там при окончании процедуры установки говорится, что прежде чем запускать кластер нужно его инициализировать:
emerge --config =dev-db/postgresql-8.4.4-r3
А затем запускаем:
/etc/init.d/postgresql-8.4 start
Для разрешения авторизации на сервере с других компьютеров сети, подкорректируем файл /var/lib/postgresql/data/pg_hba.conf, добавив строки
host all all <сетка>/<маска> trust
# хотя можно просто 0.0.0.0/0
не забыв после этого выполнить перезапуск: /etc/init.d/postgresql-8.4 restart. Естественно, что для боевого применения еще очень долго нужно работать с postgresql.conf.
Отладка и запуск
Ну и напоследок классика жанра — проверить, что PostgreSQL действительно запускается и работает:
netstat -na | grep 5432
ps ax | grep postgres
tail /var/log/messages
tail /var/lib/postgresql/data/postmaster.log
Авторизация на сервере
От рута
su postgres
psql template1
psql# ALTER USER postgres WITH PASSWORD 'newpassword';
Теперь можно из 1с-ки цепляться к серверу указав имя пользователя '''postgres''' и пароль '''newpassword''', а также почитать на тему разграничения прав доступа.
Размышления
- Насчет прав доступа к файлам прошу не обращать внимания, полагаю что Linux-пользователи понимают разницу в уровне доступа для /tmp и /usr, так что где нужно, естественно производится переключение на root (su, sudo, etc).
- Сами 1с-цы обязуют к использования библиотеку ICU (http://icu.sourceforge.net), хотя она у меня была установлена ранее (eix dev-libs/icu), но беглый просмотр исходников показал, что данная библиотека используется для Windows-сборки PostgreSQL, но вроде бы в модуле mchar (sources/contrib/mchar) в описании Makefile также встречается ее упоминание. Раскопал:
ldd /usr/lib64/postgresql-8.4/lib64/mchar.so
linux-vdso.so.1 => (0x00007fff105ff000)
libicuuc.so.44 => /usr/lib/libicuuc.so.44 (0x00007f452ea67000)
libicui18n.so.44 => /usr/lib/libicui18n.so.44 (0x00007f452e693000)
libc.so.6 => /lib/libc.so.6 (0x00007f452e337000)
libicudata.so.44 => /usr/lib/libicudata.so.44 (0x00007f452d2f7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f452d0da000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f452ced6000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x00007f452cbcb000)
libm.so.6 => /lib/libm.so.6 (0x00007f452c947000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f452c730000)
/lib64/ld-linux-x86-64.so.2 (0x00007f452efed000
Так что, если у кого будут руганья при сборке, то сначала поступить так: emerge -av dev-libs/libicu, хотя может и по зависимостям вытащит (но в ebuilde ничего такого не нашел и, скорее всего надо будет руками добавлять). - В статье автор описывает ручную установку функции datediff в кластере, однако при загрузке ранее сделанного дампа БД из ранее установленной PostgreSQL (установка на Debian из готовых deb-пакетов), функции уже имелись в наличии, правда они были только для конкретной базы, а не всего кластера (опять же могу ошибаться, хотя в Makefile модулей contrib есть упоминания про sql-файлы (равно как и наличие самих файлов), которые возможно заливаются в кластер при его инсталляции, даже если и так, то думаю не составить труда выдернуть SQL-дампы этих функций и записать их для кластера в целом).
postgres@localhost echo "\df" | psql testbase1
выдает кучу функций среди них и datediff и еще пара десятков, судя по названию которых и есть необходимый набор. - Данная статья не означает что рассмотренный способ еть Gentoo-way, однако приближение все-таки ощущается.
- Для других версий СУБД и дистрибутивов работа с патчами будет выглядеть аналогичным образом.
- Не являюсь гуру Gentoo в частности и *nix-ов в целом, поэтому не исключено что уже имеются где-то оверлеи в которых уже все отлажено и готово к употреблению, а также существуют более красивые решения.
- В данном случае поставленная цель достигнута, сервер БД установлен и инсталляция отражена в пакетном менеджере, так что какие-либо инструменты устанавливаемые в дальнейшем будут «знать» и работать с данной версией.
- На предмет как делается ./configure не смотрел, т.к. и без того получил рабочую версию.
- Если использовать USE="-1c8", то будет устанавливаться оригинальная версия с гентушными наработками без патчей от 1с.
- Сам ни в коем случае не являюсь 1с-ником, то мои познания в этой области заканчиваются инсталляцией и демонстрацией запуска 1с-ки. Так что если есть какие баги, то я о них пока не знаю.
- Не нашел как прикрепить здесь файлы, поэтому по запросу на почту скину ebuild и сам патч, хотя на самом деле все просто делается.
Источники
- man portage
- man ebuild
- man make.conf
- man patch
- man diff
- СУБД PostgreSQL
- Патчи компании 1С для СУБД PostgreSQL
- FTP-сервер компании Etersoft
- Ubuntu
- RPM дистрибутивы
- Статья на хабре
- Масса вариаций рассказывающих «как я с другом ставил...» — вносящие корректировки в уже обкатанные рецепты.