Журнал Витуса

Уволился из Postgres Professional. На этом месте я проработал 9 с половиной лет, с октярбря 2015 года. Дольше, чем на любом из предыдущих мест работы, включая, пожалуй, даже МГУ от Школы Юнг до аспирантуры.

Но вот оказалось, что работать в фирме численнстью более 500 человек и с соответствующей длины цепочками подчинения мне неуютно. Даже если я сам активно участовал выращивании этой фирмы из стартапа в 30 человек.

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

Но вот всё-таки ушел. Слишком много нервов я стал тратить на ежекватральные релизы. Нервы в моем возрасте надо беречь.

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

«Детей Пространства» я кстати дописывал как раз когда ушел из Параллелс но еще не пришел в Атлас-Кард.

X-Post to LJ

Вот почему-то в голове у современных opensource разработчиков не укладывается, что тестировать программу надо не только на той системе, где она собрана.

(я уж не говорю что у многих разработчиков не укладывается в голове что крупный программный проект надо делить на рантайм и девел-пакеты, и если что-то там можно использовать при сборке, то надеяться на наличие этого на продакшн-системе совершенно опрометчиво. В постгресе таким pg_config).

Сегодня выяснилось что мезон подготавливая информацию для запуска тестов берет полные пути и пропивсывает их в бинарный файл meson_test_setup.dat. И как-то очень неудобно получается если у нас сборка на windows делается в одном jenkins-овском workspace, а тесты гоняются совсем в другом. Правда выяснилось что этот бинарный файл сделелан питноовским модулем pickle и расковырять его вполне реально. Ну вот почему pickle, а не json, yaml или результат питновской функции repr? В старо й сборочной системе под window конфиг Data::Dumper-ом писался.

Вообще у нас регулярно возникает эта проблема.

Мы собираем постгрес или там postgis каокй-нибудь для rhel, а протестировать надо кроме rhel, на rocky, alma и oraclelinux. Собираем для Alt SP 8.2, а тестировать надо и на 8.2 и на 8.4. И так далее. Даже виндов у нас в тестовой системе штук пять - 10, 11, 2016, 2019 и 2022.

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

Все больше и больше софта перелезает на другие средства конфигурирования - cmake и meson. Вот и пострес обзавелся мезоновской билдсистемой. Причем уже в 17 версии для windows она осталась единственной. Так что приходится учиться ей пользоваться.

И тут выясняется, что те сборки 3rd-party библиотек - gettext, openssl, zstd, lz4 и еще много чего чего постгрес использует для реализации существеной функциональности, которые у нас использовались, мезон не находит.

Старая билд-система, которая генерировала проекты visual studio с помощью перловых скриптов работала в этом плане тупо - указываешь в config.pl путь к соответствующей библиотеке и вперед. (правда было дело, я там с керберосом намаялся). А теперь вот указываешь в -Dextra_include_dirs путь к инклюдам zstd, и в extra_lib_dirs соответственно к самой библиотеке, а оно и говорит, "не могу найти. Пробовали pkgconfig и cmake".

Как выясняется, для того чтобы meson-овский билд нашел libzstd и liblz4, эти библиотеки должны быть сами собраны с помощью cmake. Тогда в инсталлированное дерево попадут файлики которые cmake умееет читать и достаточно будет добавить место куда все это инсталлировано в CMAKE_PREFIX_PATH, чтобы библиотека правильно нашлась.

Пошел разбираться по списку библиотек.

lz4 - собирается cmake

zstd - собирается cmake

zlib - по станринке имеет win32/Makefile.msc для микрософтовского nmake

openssl - как собиралась собственным непохожим перловым Configure в версии 0.98, так в 3.0.15 и собирается

ossp-uuid - собрать апстримовсакую 1.8.2 не удалось, пришлось брать с сурсфоржа адаптированную под msvc. Ту же самую, пятнадцатилетней давности

icu4c - ну там лежит готовый solution для visual studio. С ее configure лучше не связываться

GNOME libxml2 - собирается cmake

GNOME libxslt - собирается cmake

GNU libiconv - вот здесь autotools в полный рост. С automake и libtool. Причем в качестве CC и AR предлагается указывать какие-то шелл-скрипты обертки вокруг настоящего компилятора и lib.exe идущие в комплекте. Но собирается.

GNU gettext - в Readme рекомендуется воспользваться инструкциями от libiconv. Однако имеется море подводных камней. Во-первых, если у нас в PATH директория windows указана раньше msys-овской, сборка ломается. (в норме мы сначала указываем нативные perl и python, потом стандарные windows директории, потом msys, а после этого запускмем vcvarsall). Во-вторых оно как-то родными средствами configure не может найти только что собранную libiconv. При этом у gettext в каждой поддиректории свой configure в результате он конфигурится куда медленнее, чем куда более объемный постгрес.

В общем конечно, тридцатилетняя эволюция (или уже 40-летняя) завела autotools куда-то не туда, и понятно почему начинают появляться альтернативы.

Берем большой-большой проект на C++, назвыается plv8. ТО есть сам plv8 не такой уж большой, но он тащит и линкует статически v8 engine - интерпретатор javascipt от Гугля, это более тысячи файлов на C++. Собираем его в дебиановский пакет под ubuntu 20.04, 22.04, debian 10, 11, 12 - работает. В куче rpm-based дистрибутивов тоже работает. Даже в AltLinux 11 и то работает.

Собираем его в Ubuntu 23.10 или 24.04 - с тем же rules-файлом, сводящимся к

make v8
make all PG_CONFIG=где-там-у-нас-сегодня-постгрес/bin/pg_config

При попытке загрузить в постгрес ругается

ERROR: could not load library "/opt/pgpro/std-15/lib/plv8-3.2.2.so": /opt/pgpro/std-15/lib/plv8-3.2.2.so: undefined symbol: _ZTVN2v88internal32WeakCollectionsBuiltinsAssemblerE

Берем so-шку (вернее даже пакет) скомпилированный в Ubuntu 22.04, ставим в 24.04 к собранному в нем постгресу - работает. То есть не просто грузится, а весь regression test suite проходит.

Почему я специально выделил выше AltLinux 11? ДА потому что в Ubuntu 23.10 и 24.04 gcc 13.2.0, в AltLinux 11 - 13.2.1, а во всех прочих поддерживаемых дистрибутивах нечто более старое. Ну 12.2.0, ну 11.4.0 или что-то такое.

Впрочем в Ubuntu 24.04 есть gcc-12. Попробовал прописать в rules CC=gcc-12 CXX=g++-12. После некоторых пинков заработало. Но лучше не стало. То есть дело тут не в версии компилятора. А скорее всего в каких-то его флагах, которые ubuntu по умолчанию подставляет при сборке пакета. Подозревал -fno-rtti. Но явное добавление -frtti не помогло.

Upd: permea_kra подкинул ссылку на баг в gcc 13 который, возможно, имеет отношение к проблеме. А, возможно, не имеет.

Upd2: Оказывается в Ubuntu noble есть не только gcc-12, но и gcc-14. Вот после сборки v8 им все работает.

До выхода ubuntu 24.04 еще два дня, а у нас уже есть первый сервер с этой ОС. Потому что ставить interim release mantic minotaur на сервер как-то некошерно. А поставить туда debian не получается, так как архитектура riscv64 пока отсутствует даже в testing - есть только в sid-е. И у альта - только в Sisyphus. Поэтому зоопарк разрастается по следующему принципу - x86_64 и aarch64 - debian, e2k - alt, riscv - ubuntu. Хотя целевая ОС там конечно alt. Но это еще пока мы портируем наш софт, глядишь у альта в 11 платформе уже эта арихтектура будет.

А у нас тут опять запускается программа стажировок

До 15 апреля принимаем заявки на оплачиваемую стажировку. Порекомендуйте нашу программу друзьям и знакомым — отправьте им нашу страницу PGStart, где необходимо оставить заявку на одну из специальностей: 

▫️С-разработчик ▫️Performance engineer ▫️Инженер по отказоустойчивости СУБД ▫️Go-разработчик ▫️QA-инженер

Стажировка — возможность проявить себя, получить практический опыт и завести полезные знакомства. По итогам сотрудничества и при взаимной симпатии зачисляем стажера в штат. 

Кандидат выполняет тестовое задание. Дедлайн выполнения тестовых — 14 мая, независимо от даты отклика и просмотра задания. 

Кандидаты, которые успешно выполнят тестовое задания, пройдут техническое собеседование — вместе с командой обсудим дальнейшие планы по работе. 

X-Post to LJ

Попросите вашего кандидата указать, что он пришел по рекомендации сотрудника vitus_wagner.

То минорный релиз задержится как минимум на неделю.

Потому что в LLVM регулярно делают несовметсимые изменения и еще месяца два назад llvmjit их ветки REL_16_STABLE компилироваться с LLVM 16 не хотел. А в Ubuntu 23.10 LLVM 16 по умолчанию. Но в основных STABLE ветках апстрим это вовремя поправил. Все замечательно. Но у нас в PostgresPro Standard есть SQL/Json, который в апстриме хорошо если попадет в 17 релиз. если за месяц до релиза не откатят (как уже случилось в 15-м). И SQLJson тоже хочет Jit-компилироваться, и в этом она абсолютно прав. Самое обидное что заметили эту проблему на неделю позже, чем могли бы, при тестировании релиз-кандидата.

Вообще постгресовый Jit на мой взгляд — вещь, от которой вреда больше чем пользы. Как правило, если тебя сложный SQL-запрос, лимитирует его производительность что угодно, только не скорость вычисления логических выражений в WHERE. А это единственное что умеет just-in-time компилировать этот jit.

И даже если у тебя используется хреновый ОРМ который генерирует развестистые where, то полное отсутствие кэширования скомпилированного кода приведет к тому что оверхед на компиляцию будет превышать выигрыш на исполнении во всех случаях, кроме full scan по очень большой таблице. А если у тебя full scan, то не ускорять вычисление выражений надо, а создавать индексы, возможно функциональные. Но почему-то апстрим уже пять лет тащит этот jit, и более того с 12 версии его сделал включенным по дефолту.

От этого у пакетов постгреса, собранных PGDG большие пробелмы с зависимостями. Бывает что пакет, собранный с RH 8.2 в RH 8.4 не поставишь, так как поменялась версия llvm.

Поэтому мы пакуем jit в отдельный пакет. Который, если есть сомнения, можно удалить, и ни на чем кроме производительности это не скажется. А на производительности, скорее всего, скажется в лучшую сторону. А если пакет jit не ставить, то и проблем с зависимостями от разных версий llvm-libs не будет.

SQL/Json на мой взгляд тоже фича не слишком полезная. Типа раз уж у нас есть в SQL-ной базе такой хороший ACID, давайте сделаем из нее немножко noSQL базу и будем хранить структурированные данные. Да еще и искать по ним и индексы строить. Но по-моему нежелание корректно преобразовать данные в реляционную модель это всегда нежелание думать головой, которое выливается в то что придется на порядки больше думать процессором.

Вот какого черта?

 set timezone_abbreviations = 'India';
 select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
 ERROR:  time zone "Pacific/Enderbury" not recognized

Где Индия, а где маленький необитаемый остров Эндербери в архипелаге Феникс? Почему из-за того, что этот остров в связи с необитаемостью снесли из timezone database в ubuntu 23.10, у меня в постгресе не прохоит тест на индийские таймзоны?

Главное мейнтейнеры timezone database уже два года как написали в файле News, что поскольку на этом острове уже 80 лет никто не живет, они его скоро выкинут.

Upd: переписка в pgsql-hackers

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

Но ведь оно, блин, так торомозит...

Запускаю qemu-system-s390x со следующими параметрами

qemu-system-s390x -smp 16 -drive file=SLES15-SP5-Minimal-VM.s390x-kvm-Build7.1.qcow2,format=qcow2 -m 4G

Оно радостно рапортует что у него аж под 14К bogomips (при том что на хосте 4800).

( lscpu )

А работает при этом медленно и печально. Ну то есть собирается то с относительно нормальной скоростью (c -j8) 26 минут постгрес и 6 минут контриб (для сравнения в user mode emulation, где число процессоров никто не ограничивает, сборка пакета постгреса (т.е. сам постгрес, плюс контриб, плюс оверхед на заворачиваение в rpm и установку Build-Requirements) занимает полчаса.

А вот тесты... make -C contrib check - пять часов, installcheck - видимо столько же - там просто тестовый скрипт не дождался и вырубил по глобальному таймауту 12 часов.

QEMU относительно свежий, 7.2. Могу поставить 8.0, но вряд ли это что-то изменит. Там changelog для этой архитектуры

• Improved zPCI passthrough device handling
• Fixed emulation of MVCP, MVCS, CHRL and CGHRL instructions
• Support for asynchronous teardown of memory of secure KVM guests during reboot

Увеличение параллельности вряд ли что-то может серьезно изменить. Там не столько параллельных процессов в тестах, чтобы задействовать сильно больше 16 ядер. Возникает странная мысль поиграться с параметрами распределения процессоров по сокетам, books и drawers (не знаю что такое books и drawers, в привычных мне писюках их не бывает). Хотя может несколько процентов я на этом выиграю, но не разы. А хотелось бы хотя бы разы.

Интересно, может помочь переход с qemu на hercules?

И вообще читают ли меня люди которые что-то в этом вопросе понимают? kondor еще в ЖЖ ходит, например?

X-Post to LJ

Тут на днях наш начальник отдела QA заявил на архкомитете, что закажет себе майку с надписью "Само ничего не делается".

Я пожалел что не ношу футболок с принтами. А то бы заказал бы надпись "Я знаю только половину всего на свете" (на фоне символа Инь-Янь контрастным цветом) Еще есть хороший лозунг: "Чтобы что-то происходило автоматом, этот автомат кто-то должен чистить и смазывать". Но для футболки длинновато.

В общем скоро 16 релиз постгреса, надо чистить и смазывать дженкинс.