Как установить патч postgresql для 1с windows

И это всё?

Ну и последнее для данной публикации это патч вводящий новый тип, точнее «контрибьютящий» некоторой количество кода внутрь нашего «адаптированного для 1С PostgreSQL». И тут нам вдруг открывается, что оказывается можно собирать свой PostgreSQL со своим набором библиотек. Интересное знание, и прежде чем вы скажете, что мы должны использовать только нативное и без расширений, я вам скажу что функционал таких модулей http://www.postgresql.org/docs/9.3/static/contrib.html — это официальный нативный функционал. Казалось бы, что такое знание совершенно не полезно.

Напомню, что дополнительных библиотек, которые собираются вместе со стандартными всего 5 в последнем (на текущий момент) патче.

• mchar
• fulleq
• fastrun (опечатка сделана специально )
• online_analyzer
• plantuner

И вы знаете мне эти библиотеки понравились. Причем каждая по своему:

online_analyzer и plantuner – сразу нас приводят на сайт http://sigaev.ru/

для НЕ желающих ходить по ссылкам, сразу скажу – эти 2 модуля добавляют известное поведение MSSQL – USEPLAN и аналог AUTOUPDATESTATS. И мне понравилось – во-первых данные библиотеки сразу же были включены в Ruby on Rails проект (точнее в их PostgreSQL), где в тот момент в силу большого количества пользователей наблюдались проблемы с производительностью с PostgreSQL. Особенную проблему вызывала как все 1С-ники знают, проблемы со статистикой записей. А тут оказалось, что можно построить адаптивный план обслуживания. Просто в PostgreSQL функция UPDATE STATS из MSQL называется ANALYZE TABLE.

Необходимость использования «хинтов» для плана запроса, говорит нам о том, что в 1С знают, что их запросы, формируемые в виде SQL достаточно нетривиальны, а также о том что оптимизатор планов запросов PostgreSQL проигрывает тому же MSSQL, где прецедентов необходимости подобного было очень мало и чаще всего причиной являлся плохой код. Вместе с этим именно это знание послужило основанием для решения НЕ использовать 1C+PostgreSQL для 1С:Зарплата и управление персоналом, в связи с особенностями текстов запросов. Но тесты на 1С ЗУП 3.0 уже показывают обратное поведение в связи с переработкой модели и методологии, которые на несколько порядков упрощают запросы. Вообще поведение последних редакций больших типовых (УТ 11.1, БП 3.0, ЗУП 3.0) позволяет с уверенностью сказать о их адаптированном поведении к PostgreSQL и Oracle. Спросите – откуда здесь появился Oracle? Мало кто знает, но PostgreSQL очень похож на Oracle. Не функционалом конечно, в Oralce он на порядок мощнее, а заложенной методологией. Существует версия что PostgreSQL рождался как OpenSource ответ большому и дорогому Oracle. Ключевым, наверное, термином здесь является PLpgSQL и остальные. Изучив PostgreSQL и его поведение, в случае если ваша компания захочет адаптировать 1С к Oracle, ваш опыт будет повторно использован, в силу особенностей архитектуры обоих. Ну и необходимо понимать, что PostgreSQL имеет версию и платную функциональность http://www.enterprisedb.com/products-services-training/subscriptions и цены там вполне себе Enterprise. Особенно для функциональности наподобие AlwayOn от MSSQL.

На самом деле, если продолжать можно понять, что 3 остальных библиотеки mchar, fulleq и fastrun – то же добавляют интересную функциональность, и даже НЕ для решений на 1С платформе. Особенно интересен новый тип MCHAR, а также то зачем для него понадобилась библиотека ICU. Что дает нам понимания, что работа в том числе с UTF-8 при использовании чистого PostgreSQL будет и есть достаточно Не тривиальной задачей, с чем вы обязательно столкнетесь, когда начнете писать приложение, которому будет необходимо хранить строки в национальных кодировках – когда например ваше приложение будет иметь пользователей из России и Канады например, да еще с Китая в добавок. Прежде чем мы начнем спорить необходимо понимать какую функциональность содержит mchar.h и файлы mcharmchar*.c. Но для этого вам понадобится знания языка С для чтения кода.

В сухом остатке. Теперь я могу точно ответить – «Мне очень нравится данный патч». Надеюсь вы понимание почему?

«Да, забудьте Вы об SQL Express» говорю я многим своим клиентам последние так года два.

Отчасти сам виноват, в 2015-ом опубликовал видео «1С 8.3 и SQL Server 2014 Express».

И это видео для многих почему-то сработало как сигнал на внедрение версии Express.

Несмотря на то, что в этом уроке я говорю о серьёзных ограничениях этой версии СУБД, да, собственно как и Microsoft, прямо пишет, — «Эту бесплатную версию стоит использовать только для теста и ознакомления».

(Цель видео в том, чтоб показать ограничения файлового варианта работы в 1С, как перейти на клиент-сервер и показать ограничения версии Express).

И лишь в некоторых случаях, когда база 1С совсем малая и с базой работает пара пользователей, нет нагрузок, тогда, может быть смысл использовать эту СУБД для реальной работы в 1С.

Отличия PostgreSQL от MS SQL читайте здесь >>

Но большинству конечно ограничения не позволят работать «нормально» в клиент-сервере.

Как минимум нужна версия Standard.

Альтернативой MS SQL всегда был и остается PostgreSQL.

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Абсолютно бесплатная*  СУБД с реализацией как под Linux, так и на Windows.

Бытует мнение, что PostgreSQL нормально работает только на Linux.

Но это ужа давно не так (Хоть изначально он и разрабатывался под UNIX-подобные платформы).

Сегодня PostgreSQL можно смело использовать и на Windows , (Пользователей 50-70- одновременно работающих в 1С будет держать нормально, до 15-ти, даже не нужно никаких доп. настроек!).

Если у Вас пользователей будет больше, тогда лучше брать MS SQL.

Конечно, в сети можно встретить примеры, (особенно в последнее время) когда  PostgreSQL  работает на сотнях пользователей в 1С, но я такого в живую не видел (чтоб без косяков, при большом количестве запросов) чтоб СУБД работала также быстро и хорошо, как и на MS SQL standard, например.

Вот одна из причин: PostgreSQL не умеет работать многопоточно!

Иногда в интернете, можно наткнуться на статью что PostgreSQL грузит только одно ядро на 100%, и мол не работает с многоядерными архитектурами.

Знайте, что это не так! (Вернее не совсем так!)

PostgreSQL грузит все ядра, только если есть соответствующее количество запросов .

Один большой запрос действительно может  на 100% загрузить одно ядро вашего сервера так как

1 запрос = 1 поток! (На этой СУБД).

 Но если запросов будет много, соответственно и все ядра будут задействованы также.

PostgreSQL способен задействовать все ядра вашего сервера!

Каждое ядро может дать нам несколько потоков, например как минимум два, и уже, чтоб задействовать 2 ядра (4 потока) будет достаточно отправить на СУБД 3 — 4 запроса.

Помните?

1 запрос = 1 поток.

Другими словами, не распараллеливается выполнение одного запроса.

Нет многопоточности! в рамках одного запроса  — это одна из причин, почему PostgreSQL работает медленнее MS SQL.

Один большой запрос может стать «узким местом» в производительности вашей 1С на этой СУБД.

Есть, конечно, еще много вопросов по «бєкапу», настройке и оптимизации PostgreSQL в том числе и под крупные внедрения, но это все подробно мы будем обсуждать уже на курсе: Установка и настройка 1С 2017.

Как известно без специальных «патчей» от компании 1С СУБД-шка работает не стабильно, вылетает + есть  проблемы с производительностью.

Но с «пропатченой» таких серьезных проблем обычно не возникает.

Дело в том что в 1С часто используются временные таблицы, а PostgreSQL плохо сними дружит.

«Патчи» как раз правят эти и другие «косяки 1С» в официальном релизе.

Теперь о главном!

В феврале 2015 года наиболее известные российские разработчики PostgreSQL основали компанию «Постгрес Профессиональный» (Postgres Professional), целью которой стало развитие СУБД PostgreSQL и оказание полного спектра связанных с ней услуг.

И если раньше я скачивал PostgreSQL на сайте 1С (Поддержка пользователей), то сегодня

Я беру дистрибутив на сайте postgrespro.ru (Как для Windows так и для Linux).

Внимание Важно!

PostgresPro Standard и Enterprise — платные!

https://postgrespro.ru/products/postgrespro#license

Качайте просто «пропатченую 1С» по ссылке ниже:

https://postgrespro.ru/products/1c

Enterprise — действительно очень дорогой продукт, а вот Standard на момент написания статьи, приобретается как годовая поддержка.

Другими словами Вы покупаете поддержку на год и получаете версию Standard в *подарок*.

Второй способ получить PostgreSQL бесплатно:

Для этого нужно скачать на сайте поддержки пользователей 1С, нужный Вам дистрибутив PostgreSQL со всеми патчами для 1С, и работать бесплатно на этой СУБД.

На момент написания статьи, доступна версия PostgreSQL 9.6.5 для 1С Предприятия.

Все в *свободном доступе*, можно скачать и установить у себя.

Делюсь ссылкой, друзья >>>

Дело в том, что Postgres Pro (основанный на PostgreSQL) уже содержит все нужные «патчи» для 1С Предприятия.

И Вы не «паритесь» поиском каких-то  критически важных «патчей» все уже включено в эту сборку, это удобно.

Даже для Windows включены дополнительные «патчи» повышающие отказоустойчивость еще не успевшие войти в стабильный релиз, например, включены «патчи», которые исправляют проблему с правами доступа и критический баг с остановкой Postgres.

Установка:

Качаем инсталлятор на сайте по ссылке выше.

И приступаем к установке.

Конечно я рекомендую ставить СУБД на Windows Server 2016.

Установка PostgreSQL на Windows совсем не сложная, но во избежание каких-то возможных проблем, смотрите ниже в скриншотах весь процесс пошагово: 

Как видно уже на скрине, сборка действительно под 1С-ку. «PostgresPro 1C 9.6».

Принимаем условия лицензионного соглашения «Принимаю».

И установим все нужные компоненты.

Клик по кнопке «Далее».

Укажем каталог где будет установлен сам PostgresPro (Можно оставить каталог по умолчанию).

Клик по кнопке «Далее».

Теперь нужно указать каталог для наших баз данных.

На вкладке параметров порт 5432 можно оставить по умолчанию (Если у Вас он свободный на момент установки).

Затем птичку «Подключение с любых IP адресов» убираем если Сервер 1С и СУБД будут располагаться на одном сервере.

Иначе оставляем все как есть.

Локаль: — Russian, Russia.

Супер пользователя можно оставить по умолчанию «postgres».

И обязательно создадим пароль для него.

Птичку возле «Провести оптимизацию параметров» оставляем по умолчанию.

И клик по кнопке «Установить».

Все готово! можно создавать базу используя утилиту администрирования серверов 1C.

Для удобства администрирования, рекомендую еще установить дополнительно и PGAdmin 4.

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Сборка PostgreSQL для 1C на Gentoo

Возникла необходимость поднять на Gentoo PostgreSQL-сервер для 1С-ки. Как всем известно одинэсовцы являются знаменитыми костылестроителями и в данном случае СУБД PostgreSQL не обошли стороной.

Почему Gentoo? Потому что данный дистр можно заточить именно для решения узко определенной задачи, со всеми преимуществами оптимизации USE-флагов, в отличие от бинарных дистров, где много вшито лишнего, а сборка собственных пакетов означает отказ от пакетных менеджеров (может и не так, не знаток этого вопроса), что сильно ухудшает поддержание инсталляции в актуальном состоянии. Ну и к тому же, на то он и гентушник раз любит сам готовить, а не использовать готовое.

Блуждания в интернете не принесли желаемого результата, а именно не нашлось ebuild-а, для такой задачи, хотя упоминания имеются, на неком ростовском сервере, то некто выкладывал на форуме (может плохо искал), то изобретали костыли с использованием rpm2cpio — над пропатченными сырцами, а то и вовсе редхатовскими бинарниками, но сим не есть gentoo-way, а хочется именно чтобы собрать из сырцов, без левых зависимостей, установить в каталоги стандартные для этой системы, а не какие-то /opt, и чтобы пакетный менеджер знал о нашей инсталляции и считал ее родной, с учетом make.conf и USE-флагов.

Имеется хороший ресурс ftp://ftp.etersoft.ru/pub/, оттуда берем патчи 1С-ки для PostgreSQL 8.4.4 — ftp://ftp.etersoft.ru/pub/Etersoft/Postgre@Etersoft/8.4.4/sources/postgresql-8.4eter-8.4.4-alt1.1.src.rpm, т.к. у самих 1С-цев на сайте патчи только для версии 8.4.1 (опять-таки может плохо искал, а может они и подходят для нашей версии). Кроме того, етерсофтцы опять таки патчат некоторые наработки одинэсевцев, исправляя их баги.

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

Итак, наш рецепт приготовления будет состоять в следующем:

• скачиваем сырцы и патчи на etersoft.ru
• готовим локальный оверлей
• наложение гентушных патчей на оригинальные исходники
• наложение етерсофтных патчей поверх гентушных
• снятие diff-а с гентушных сырцов PostgreSQL и патченного етерсофтом, в целях получения своего патча
• оформляем патч для кормления epatch’а
• оформляем наш ebuild
• ловля блох (багов) сборки
• тюнинг системы
• напутствия жаждущим

Где мы находимся

В качестве версии СУБД будем использовать версию 8.4.4, хотя сейчас уже 1с-цы выложили патчи для 9-й версии, думаю не будет сложно и их адаптировать по аналогии.

Ранее установленная ОС Gentoo x86_64 на домашней машине [4G 1333, 1Tb] (самопальное ядро Linux localhost 2.6.36-gentoo-r5 #1 SMP Sun Dec 26 21:57:53 YEKT 2010 x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz GenuineIntel GNU/Linux и все что на нем крутится также собрано gentoo-способом), которая содержит очень много лишнего для боевого сервера узко-направленного значения, но это нам не помешает, а скорее будет проще не отвлекаться на шлифовку ядра, если таковое требуется, о чем мне не ведомо.

Что мы имеем

Для начала обновим порты, это уж кто как предпочитает, я делаю так:

# 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 вместе с патчами отсюда ftp://ftp.etersoft.ru/pub/Etersoft/Postgre@Etersoft/8.4.4/sources/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, мне это показалось саморекламой (есть ли нарушения GPL? или BSD, или какая лицензия у PostgreSQL и патчей?), поэтому данный патч не был использован, к тому же при сборке PostgreSQL все же хочет файл libpq, так что ребята недостарались)
• postgres_datalen.patch — что-то меняет для успешной инициализации кластера PostgreSQL (initdb)
• postgresql-1c-8.4.patch — рихтует Makefile для сборки модулей написанных 1с-цами — fulleq, fasttrun, mchar, плюс рихтует конфиг для PostgreSQL
• postgresql.conf.sample.patch — как видно из названия, также рихтует конфиг (честно говоря не понимаю для чего это сделано, ребята полагают, что PostgreSQL будут ставить полные нули которые не осилят чтения документации а-ля MSSQL)
• postgresql-no_transaction_blocks.patch — этот и следующие два патча, по мелочам вносят правки
• postgresql-perl-rpath.patch
• postgresql-tmp_table_cleanup.patch
• rpm-pgsql.patch — опять самопиар для сборки RPM-пакета, также не понял зачем менять стандартную директорию размещения БД-х 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 < <patch-name>, но анализ лог-файлов показал, что epatch использует такую хитрую комбинацию ключей. Теперь считаем что у нас получились эталонные исходники, на которые будет ebuild накладывать патчи для 1с-ки.

Подготовим площадку для дальнейших экзекуций:

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-x86.xml?part=3&chap=6), выяснил что выполняются по шагам следующие действия:

• ebuild /path/to/ebuild unpack
• ebuild /path/to/ebuild prepare
• ebuild /path/to/ebuild compile
• ebuild /path/to/ebuild install
• 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 

где видно, что путь к файлу начинается с обратного слэша .., есть предположение что данный патч писался под оффтоповой осью, однако дальнейшие слэши все же правильные, к тому же тут указывается версия 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
# Это наш патч, который можно отослать другу-гентушнику
diff -urdN ../postgresql-8.4.4.orig ../postgresql-8.4.4 > ../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 $

— ревизию ebuld-файла

Далее в строке можно поменять

DESCRIPTION="PostgreSQL server with patchset from 1C company. I'm was hack the Internet"

Менять обязательно:

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

Как видим система по-умолчанию выбирает нашу сборку (когда 9 версия будет размаскированной, что-то придется поменять в /etc/portage). Emerge увидел два дерева портежей — системный и наш локальный, среди флагов USE появился флаг 1c8.

Для 1с-сборки PostgreSQL, помимо самого флага 1с8, флаги tcl, perl, python, selinux не являются обязательными, т.к. вроде бы являются биндингами к соответсвующим ЯП, насчет остальных не уверен.

А теперь ставим:

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.

Почистим /tmp, больше не пригодится

rm -rf /tmp/postgresql

и небольшой лоск (т.к. делал от рута)

chown portage:portage -R /usr/local/dev-db

Послеустановочный тюнинг

В интернете много сообщений на тему руганья 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

По рекомендации из того же файла проверяем файл /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» может себя не исчерпать, то делаем вмешательство в скрипт запуска/останова — где-нибудь в начале файла, перед описанием функций, добавляем:

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
host all all <сетка>/<маска> md5
# хотя можно просто 0.0.0.0/0

не забыв после этого выполнить перезапуск: /etc/init.d/postgresql-8.4 restart

Отладка и запуск

Ну и напоследок классика жанра — проверить, что 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 в кластере, а также еще чего из SQL-диалекта, однако при загрузке ранее сделанного дампа БД из ранее установленной PostgreSQL (установка на Debian из готовых deb-пакетов), функции уже имелись в наличии, правда они были только для конкретной базы, а не всего кластера (опять же могу ошибаться, хотя в Makefile модулей contrib есть упоминания про sql-файлы, которые возможно заливаются в кластер при его инсталляции, даже если и так, то думаю не составить труда выдернуть SQL-дампы этих функций и записать их в шаблон).

postgres@localhost echo "df" | psql testbase1
выдает кучу функций среди них и datediff и еще пара десятков, судя по названию которых и есть необходимый набор.

• Данная статья не означает что рассмотренный способ еть Gentoo-way, однако приближение все-таки ощущается.
• Для других версий СУБД и дистрибутивов работа с патчами будет выглядеть аналогичным образом.
• Не являюсь гуру Gentoo в частности и *nix-ов в целом, поэтому не исключено что уже имеются где-то оверлеи в которых уже все отлажено и готово к употреблению, а также существуют более красивые решения.
• В данном случае поставленная цель достигнута, сервер БД установлен и инсталляция отражена в пакетном менеджере, так что какие-либо инструменты устанавливаемые в дальнейшем будут «знать» и работать с данной версией.
• Если использовать USE=»-1c8″, то будет устанавливаться оригинальная версия с гентушными наработками без патчей от 1с.
• Сам ни в коем случае не являюсь 1с-ником, то мои познания в этой области заканчиваются инсталляцией и демонстрацией запуска 1с-ки. Так что если есть какие баги, то я о них пока не знаю.
• Моя первая статья, надеюсь кому поможет.

Ресурсы

• man ebuild
• man make.conf
• man patch
• man diff
• СУБД PostgreSQL
• Патчи компании 1С для СУБД PostgreSQL
• FTP-сервер компании Etersoft

Другие рецепты инсталляций

• Ubuntu
• RPM дистрибутивы
• Статья на хабре
• И еще масса вариаций рассказывающих «как я с другом ставил…» — вносящие корректировки в уже обкатанные рецепты.

Файлы

В архиве прилагается готовый ebuild и результирующий патч Медиа:Gentoo-postgresql-1c8.zip.