Как-то давным давно, на одной из постгресовых конференций я познакомился с Виталием. Тогда мы общались на разные постгресовые темы, обсуждали постгрес, инструменты вокруг него. И в то время были популярны истории про HighAvailability - на этой волне популярности появлялись разные инструменты. Виталий не прошел мимо и создал postgresql_cluster (https://github.com/vitabaks/postgresql_cluster) - автоматизацию которая объединила в себе набор несвязанных компонентов в один целостный инструмент. Инструмент получился весьма удачный и я нередко отвечая на вопросы про HA, рекомендовал присмотреться и попробовать postgresql_cluster.
Прошло несколько лет, инструмент не только продолжил развитие, но и перерос в продукт. Это очень круто - за столь длительное время, автор не потерял к нему интерес и продолжает поддерживать и добавлять новые функции. Поддержка ПО мне всегда напоминала бесконечный марафонский забег без финишной прямой и чем дольше удается пробежать, тем больше это вызывает уважения.
Виталий ты супермегакрут, желаю тебе продолжать бежать, желаю находить силы для поддержки и развития, придумывать новые идеи для новых фич, получать больше пользователей и адекватной обратной связи, ну и вообще успехов!🍾🎉
Но уплощение выполняется только если оно не приведет к появлению в плоском списке более join_collapse_limit элементов (значение параметра по умолчанию — 8). В данном примере при любых значениях параметра, меньших 5, узел JOINEXPR не будет уплощен.
Несколько раз перечитал, мне кажется что первое предложение противоречит второму. То есть первое предложение говорит "уплощать пока итоговое значение в списке меньше 8". Второе говорит наоборот "НЕ уплощать пока итоговое значение меньше 5+3"
Все ли верно в цитате? или таки в первом предложении есть лишняя частица "не"?
Автор статьи прямо указывает что НЕиспользовать большие страницы НЕ рекомендуется — Especially when not utilizing huge_pages (not recommended)
С моей точки зрения большие страницы имеет смысл использовать если памяти больше 8-16GB, на калькуляторах с меньшим объемом памяти лишняя суета с настройкой.
Репортинг памяти самим постгресом, сделан не очень удачно имхо (((.
Репортинг в консоль работает только для текущей сессии, при этом нельзя также взять и посмотреть репорт по соседней сессии, только через функцию pg_log_backend_memory_contexts сбросить дамп в лог и потом грепать его. Печаль.
Планы расширения конечно есть, на очереди odyssey, patroni и pgbackrest (потом wal-g, и возможно pg_probackup т.к. с ним меньше всего опыта).
Дашбордов нет, пока руки не дошли. Первым по плану для графаны, потом возможно для заббикса. С последним сложно, т.к. у меня вообще его нигде нет.
Большое спасибо за развернутый ответ по пп 1 и 2, так стало сильно понятней.
Но по п.3 в итоге все равно получается так что может быть только один метод Get и он всегда возвращает только либо успех (err == nil), только либо ошибку (err != nil).
Спасибо за статью, есть несколько вопросов по п.1 «Используем интерфейсы при разработке»:
1. как быть если методов относительно много? в той же redis библиотеке их довольно много — выходит что каждый внешний метод нужно оборачивать в свой или идти в сторону кодогенерации?
2. как быть если внешний метод возвращает какой-то свой интерфейс? например pgx.Begin, возвращает транзакцию pgx.Tx (которая тоже интерфейс) — для транзакции тоже нужно писать свой интерфейс обертку и затем писать обертки для методов?
3. в обертках всегда возвращается «успех», а как быть если нужно также тестировать и случаи когда возвращаются ошибки? Ну то есть как сделать так чтобы метод-обертка мог возвращать не только успех, но и error.
Лично мне — на случай если нужно локально что-то выполнить, например погнать тесты или собрать бинарник.
Судя по вашему комментарию я так понимаю что вы знаете о GH Actions больше чем я, тогда вам встречный вопрос — нет ли у вас готовых примеров (с гитхаба) по сборке докер образов и их выкладке в registry. Я понимаю что описание можно найти в их документации, но хотелось бы увидеть как это устроено в реальных workflow.
Согласен, периодически от него подгорает, но пока в целом Makefile удовлетворяет мои скромные потребности. За альтернативы спасибо, а из этих двух сами к чему склоняетесь больше и почему?
Зависит от кейса:
— если «что-то» что лежит в коде, то просто кладем в целевой контейнер через COPY/ADD
— если «что-то» принадлежит другому пакету (корневые сертификаты), то это также можно через multi-stage сделать — установить пакет в одном контейнере и затем оттуда скопировать в целевой.
— если «что-то» создается самим пользователем (конфиги например) — то это создается отдельно до запуска контейнера, а при запуске контейнера подкладывается через тома (volumes).
Спасибо за проделанную работу, но перевод хромает. Переводчку надо повышать свою тех.грамотность и избегать англицизмов (консюмер) и английских слов в переведенном тексте (fan-out, amplification и т.п) — для большинства слов уже давно есть устоявшиеся термины на русском языке.
Как-то давным давно, на одной из постгресовых конференций я познакомился с Виталием. Тогда мы общались на разные постгресовые темы, обсуждали постгрес, инструменты вокруг него. И в то время были популярны истории про HighAvailability - на этой волне популярности появлялись разные инструменты. Виталий не прошел мимо и создал postgresql_cluster (https://github.com/vitabaks/postgresql_cluster) - автоматизацию которая объединила в себе набор несвязанных компонентов в один целостный инструмент. Инструмент получился весьма удачный и я нередко отвечая на вопросы про HA, рекомендовал присмотреться и попробовать postgresql_cluster.
Прошло несколько лет, инструмент не только продолжил развитие, но и перерос в продукт. Это очень круто - за столь длительное время, автор не потерял к нему интерес и продолжает поддерживать и добавлять новые функции. Поддержка ПО мне всегда напоминала бесконечный марафонский забег без финишной прямой и чем дольше удается пробежать, тем больше это вызывает уважения.
Виталий ты супермегакрут, желаю тебе продолжать бежать, желаю находить силы для поддержки и развития, придумывать новые идеи для новых фич, получать больше пользователей и адекватной обратной связи, ну и вообще успехов!🍾🎉
Всё, понял теперь, спасибо :)
Посмотрите тут.
Несколько раз перечитал, мне кажется что первое предложение противоречит второму.
То есть первое предложение говорит "уплощать пока итоговое значение в списке меньше 8".
Второе говорит наоборот "НЕ уплощать пока итоговое значение меньше 5+3"
Все ли верно в цитате? или таки в первом предложении есть лишняя частица "не"?
С моей точки зрения большие страницы имеет смысл использовать если памяти больше 8-16GB, на калькуляторах с меньшим объемом памяти лишняя суета с настройкой.
Репортинг в консоль работает только для текущей сессии, при этом нельзя также взять и посмотреть репорт по соседней сессии, только через функцию pg_log_backend_memory_contexts сбросить дамп в лог и потом грепать его. Печаль.
Дашбордов нет, пока руки не дошли. Первым по плану для графаны, потом возможно для заббикса. С последним сложно, т.к. у меня вообще его нигде нет.
Но по п.3 в итоге все равно получается так что может быть только один метод Get и он всегда возвращает только либо успех (err == nil), только либо ошибку (err != nil).
1. как быть если методов относительно много? в той же redis библиотеке их довольно много — выходит что каждый внешний метод нужно оборачивать в свой или идти в сторону кодогенерации?
2. как быть если внешний метод возвращает какой-то свой интерфейс? например pgx.Begin, возвращает транзакцию pgx.Tx (которая тоже интерфейс) — для транзакции тоже нужно писать свой интерфейс обертку и затем писать обертки для методов?
3. в обертках всегда возвращается «успех», а как быть если нужно также тестировать и случаи когда возвращаются ошибки? Ну то есть как сделать так чтобы метод-обертка мог возвращать не только успех, но и error.
Судя по вашему комментарию я так понимаю что вы знаете о GH Actions больше чем я, тогда вам встречный вопрос — нет ли у вас готовых примеров (с гитхаба) по сборке докер образов и их выкладке в registry. Я понимаю что описание можно найти в их документации, но хотелось бы увидеть как это устроено в реальных workflow.
— если «что-то» что лежит в коде, то просто кладем в целевой контейнер через COPY/ADD
— если «что-то» принадлежит другому пакету (корневые сертификаты), то это также можно через multi-stage сделать — установить пакет в одном контейнере и затем оттуда скопировать в целевой.
— если «что-то» создается самим пользователем (конфиги например) — то это создается отдельно до запуска контейнера, а при запуске контейнера подкладывается через тома (volumes).