💬 Greenplum: Репозитории заархивированы

Недавно стало известно, что большая часть репозиториев на GitHub Greenplum была заархивирована. В связи с этим у многих возникли вопросы о будущем проекта.

🔍 Комментарий от Arenadata DB:
Разработка Greenplum в рамках open source, скорее всего, будет приостановлена. Дальнейшее развитие проекта будет происходить силами нового правообладателя проекта — компании Broadcom, и сосредоточится на коммерческой версии VMware Tanzu Greenplum.

❓ Нигде не удалось найти прямых подтверждений этому. На сайте Pivotal все еще указаны лицензии по использованию Open Source вплоть до 7-й версии, а также висит следующее уведомление:

🔈 NOTICE:
As part of VMware’s integration with Broadcom, the Tanzu Network domain will remain available to customers until June 7th, 2024, at which point it will redirect to Broadcom’s Support Portal. The associated Tanzu Network registry will remain in read-only mode starting on June 7th, 2024 and will be available until July 15th, 2024 to continue to support using existing OCI artifacts without impact as you transition to Broadcom systems. Please refer to this knowledge base article (ID#: 367105) for all dates and additional information about automation resources.

👍 Что это значит?
Есть вероятность, что просто из-за смены владельца репозитории могут быть перенесены в другое место.

💡 А вы знали, что большинство ошибается насчет PID 0 из-за одной неточности в Wikipedia, сделанной 16 лет назад ? Которая уже исправлена.
Тут челик поясняет за историю PID 0 и кишках запуска ядра.

🔍 PID 0 существует. Это процесс, который запускает ядро.

👎 PID 0 не управляет памятью. В ранних версиях Unix были некоторые задачи, связанные с управлением памятью, но PID 0 давно этим не занимается. Ошибочно связывать PID 0 с такими задачами, как пейджинг или своп.

⚙️ Роль PID 0:
- Инициализация ядра: Во время загрузки ядро инициализирует различные компоненты и создает первый процесс с PID 0.
- Ожидание (idle): PID 0 затем переходит в режим ожидания, готовый к планированию новых задач.
- Управление задачами: Первые задачи, созданные ядром, помогают инициализировать систему. Первая из них в конечном итоге становится процессом инициализации (PID 1) в пользовательском пространстве.

🤯 А вы знали, что Redis с версии 7.4 более не OpenSource.

⚙️ Появился форк под названием Valkey, основанный на версии Redis 7.2.

😶‍🌫️ Valkey уже поддерживается облаками AWS, Oracle и Google.
🚀 Кроме того они являются основными контрибьюторами.

👀 Подписан на канал Админим с Буквой: в целом чел пишет попсовую хуйню от «как сменить пароль в гитлабе локально» до рассказов «как он стал менеджером» с кучей ненужных вакансий, судя по позиции и описаниям, далеко не звездных.

Так вот, на днях публикует свой «инструмент» для проведения собеседований. Внимание ‼️ в гугол таблице :) я заитригован моментально, но чтобы не читать очередной чей-то высер, я ожидал полистать комментарии, которые были отключены по неясной сперва для меня причине.

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

Для тех, кто не способен прочитать в оригинальном посте что вопросы - моя субъективная история, желаю чтобы вы никогда не попадали на руководящие должности.

Желание неудачи другим людям несогласным с твоим субъективным мнением это конечно круто… это первая ступень в походе за позицией СТО, я так понимаю. Какава профессиональность!

🤦‍♂️И еще, как вы думаете почему в канале не было постов больше месяца? да потому что типок работает в консалтинге по секьюрити, клиента которого не так давно зашифровали к хуям.
Мне очень нравится читать советы и методики от людей которые хапают неудачи полной грудью, имея лишь цель поделиться своим мнением, о котором часто никто не спрашивал)

Ну и в довесок, кому нужен инструмент, если он не масштабируется и применим только к «твоей» компании, где ты лучше всех все знаешь? Зачем его тогда шерить? показать как ты умеешь таблицы составлять? чтобы более крутые менеджеры тебя заметили ?

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

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

Обходите идиотов стороной, друзья)

📈 Недавно задался, зачем для BI-аналитики сгружать все данные с различных источников в один Data Warehouse (DWH), почему бы не читать напрямую из тех мест, где лежат исходные данные. На что получил вполне разумный ответ, что данные нужно объединять друг с другом (JOIN) для BI-аналитики. 🤔 На что задался вопросом, а есть ли такие инструменты, которые позволяют читать данные из различных источников и объединять их. ♻️

💡 Оказывается такой инструмент есть -- Trino (бывший Presto).
🗃 Поддерживает классический ANSI SQL, кеширует в Redis.

DWH считается не совсем современным и трендовым решением: данные нужно хранить там, где они хранятся (Postgres, MySQL, Oracle, MongoDB, etc.)

🎙 Тут челик на VK Conf рассказывает как они построили BI-аналитику поверх Trino и Superset.

😎 Все сложное можно сделать просто, если что-то остается сложным, то скорее всего вы пошли не по тому пути. Ищите простое решение или несколько простых решений в цепочке.

Логическая репликация в PostgreSQL. Репликационные идентификаторы и популярные ошибки

Весь процесс логической репликации в PostgreSQL основан на использовании репликационных идентификаторов. 📋

Подготовка:
🔍 Проверка наличия в реплицируемых таблицах первичного ключа или индекса, соответствующего минимальным требованиям и задействованного в REPLICA IDENTITY USING INDEX, либо назначение REPLICA IDENTITY FULL.
🛠️ Репликационные идентификаторы необходимы для однозначной идентификации изменяемых или удаляемых строк при репликации команд UPDATE и DELETE.

Репликационные идентификаторы:

🚫 Их можно не настраивать или отключить, если планируется реплицировать только команды INSERT. Главное — исключить из публикации команды UPDATE и DELETE.
⚠️ Для актуальных данных из активно изменяющихся таблиц, где отсутствуют первичные ключи или уникальные NOT NULL индексы, настройка репликационных идентификаторов обязательна. В противном случае UPDATE и DELETE могут привести к отмене транзакций на мастере, что является нежелательным на рабочей базе.


🗂️ Этот запрос поможет вам выявить таблицы без настроенных репликационных идентификаторов.

SELECT pgn.nspname || '.' || pgc.relname AS "Таблицы без репликационных идентификаторов"
  FROM pg_class AS pgc,
       pg_namespace AS pgn
  WHERE pgn.nspname !~ '^(?:pg_.*|information_schema)$'
    AND pgc.relreplident IN ('n', 'd')
    AND pgc.relkind IN ('r', 'p') 
    AND pgc.oid NOT IN (SELECT pgi.indrelid FROM pg_index AS pgi WHERE pgi.indisprimary)
    AND pgc.relnamespace = pgn.oid
    ORDER BY 1;
---

🦄 Не забывайте правильно настраивать репликационные идентификаторы для успешной работы логической репликации!

🚀 Удаление устаревших артефактов в GitLab

🔧 Если в GitLab не были установлены параметры для автоматического удаления устаревших артефактов, то после конфигурации в старых репозиториях артефакты не будут удалены автоматически. Для освобождения места можно использовать скрипт, который пройдется по проекту, соберет все Jobs (кроме первой страницы — 100 последних Jobs) и удалит из них все артефакты. 🗑️