Наличие грифа совершенно секретно на некоторых разработках как бы намекает, что Вы (мы, они и все остальные) не должны знать об этом.
Если честно, то мне немног непонятно насчет наличия/отсутствия этого грифа на данной разработке, а он должен быть и почему (если он есть/был) человек его нарушил (если нарушил, если он был).
В офф репеpg_probackup увы ни слова про 3-ю версию, да оно наверно и не нужно уже, поезд ушел. Есть другие инструменты которые обладают довольно неплохим функционалом и за последние годы были неплохо доработаны и оттестированы.
Про банки я пока слышал что только Сбер перевел АБС на рельсы их БД Pangolin, но не уверен насколько это правда и в полной ли мере все теперь у них на Pangolin ибо маркетинг и реальность сильно расходятся.
В остальном кажется, что банковские АБС и процессинг как сидели на Oracle так и сидят. Могу конечно ошибаться, уже лет 10 как ушел из банковской сферы.
>32х в банках как правило хватает в среднем на 1-1,5 месяца.
Да пусть хоть на 7 дней, если сработает штатный механизм защиты от xid wraparound
> а теперь то это зачем
Это Вы спросите у OpenAI которые используют 50 реплик пг чтобы осилить такие нагрузки. Кажется, что у тех же банков поток нагрузки будет поменьше в масштабе страны, хотя если приложение написано как кусок г... там ничего уже не поможет.
Спасибо за статью. Остается ждать когда-же что-то появится в опенсорсе и можно будет пощупать, пока в репах Тантор на github очень скудно.
P.S. На самом деле у всех довольно скудно, PostgresPro тоже ушла в закрытие кода многих продуктов, взять хотя бы probackup. В общем типовой кровавый энтерпрайз и вендор лок, только вид сбоку.
при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность
Это реальный кейс клиента когда 1 сервер с PostgreSQL должен держать тысячи соединений? Или это тестовый кейс, для того чтобы показать узкое место PostgreSQL?
Может просто не делать так? Не создавать тысяч соединений? Сделать 50 реплик и распределить соединения по ним?
Насколько я понял, проблема проявляется при высокой параллельности и при использовании множества SAVEPOINT. Но я не понял опять же - это реальный кейс у клиента или это искусственно созданная ситуация чтобы показать проблемное место PostgreSQL? Если это реально кейс клиента, то у скольких клиентов проявляется такая проблема? Если из 1000 клиентов она проявляется у 1 клиента, то это 0,1% и возникает вопрос - а так ли это важно? Ну я про то, что нужно вложиться в решение этой проблемы на уровне устранения в коде PostgreSQL, не проще ли устранить проблему иными способами у этого 1-го клиента, например изменением архитектуры приложения или модели работы с СУБД и тп?
Это как с 64-х битным счетчиком транзакций, все упарываются внедряя его в коммерческие форки PostgreSQL, но никто не показывает статистику - у скольких клиентов существует такая проблема с переполнением счетчика? У 2-3 клиентов из 10000? Или у 150 клиентов из 10000? А сколько из этих клиентов не смогли воспользоваться штатным механизмом PostgreSQL чтобы предотвратить переполнение счетчика транзакций и кластер реально встал колом? Данных нет. Никто их не показывает, зато все пишут что у них 64-х битный счетчик транзакций, это мега-важный плюс покупки коммерческого форка PostgreSQL. Так и хочется сказать - Вы серьезно?
Интересно, а как они исправили баги в ClientHello если PR запросы в одном случае закрыт и не влит в мастер, во втором он висит открытым и тоже не влит в мастер?
Получается публичная репа это просто фикция и в реальности сборки делаются на основе какой-то закрытой репы к которой у сообщества нет доступа? Тогда где гарантия, что готовые сборки соответствуют кодовой базе публичной репы? Нигде, опять же получается.
MR в кодовую базу телеграм с исправлением багов не приняли. Один точно закрыли, в десктоп. Второй в ios пока висит открытым, но кажется и его не примут. С андроид непонятно, да и мне лично он не интересен.
Все это прекрасно, но что толку от навороченного mtproxy если тспу блокируют к нему доступ? А создатели телеграм как бы и не собираются исправлять баги в реализации tls чтобы скрыться от тспу.
Круг замкнулся, проще использовать сами знаете какие решения и не мучиться с mtproxy
Сколько уже лет эта тема движется? 5 или 7? Когда же наконец будет хоть какой-то сдвиг в ваниле? Я честно говоря уже потерял все треды где там патч с поддержкой 64-битного счетчика пытаются ребейзить до текущей версии пг и оттестировать. 2 человека что-ли над этим работают, кажется что это очень мало и даже в 20-й версии пг мы не увидим полностью 64-битный счетчик во всех местах.
Оркестратор в офф репе https://github.com/github/orchestrator не развивается и не будет развиваться больше, репа в архивном режиме, так что я бы не стал его использовать.
Есть форк от Percona https://github.com/percona/orchestrator но и он официально не является сопровождаемым, но там хотя бы исправляют хоть какие-то найденный ошибки.
Если Вы не умеете готовить мускуль и правильно писать запросы, делать DDL, то и на постгрес Вы словите такого же рода проблемы просто в другом месте. С любой БД можно подскользнуться и больно упасть если не вникать в тонкости и нюансы работы базы. Речь конечно про хайлоад, а не пет-проект с 10 посетителями в час.
Будем ждать пакетов для ОС, а то это конструктор лего получается. Спасибо!
Наличие грифа совершенно секретно на некоторых разработках как бы намекает, что Вы (мы, они и все остальные) не должны знать об этом.
Если честно, то мне немног непонятно насчет наличия/отсутствия этого грифа на данной разработке, а он должен быть и почему (если он есть/был) человек его нарушил (если нарушил, если он был).
В офф репе pg_probackup увы ни слова про 3-ю версию, да оно наверно и не нужно уже, поезд ушел. Есть другие инструменты которые обладают довольно неплохим функционалом и за последние годы были неплохо доработаны и оттестированы.
>Просто одно слово: "Банки".
Про банки я пока слышал что только Сбер перевел АБС на рельсы их БД Pangolin, но не уверен насколько это правда и в полной ли мере все теперь у них на Pangolin ибо маркетинг и реальность сильно расходятся.
В остальном кажется, что банковские АБС и процессинг как сидели на Oracle так и сидят. Могу конечно ошибаться, уже лет 10 как ушел из банковской сферы.
>32х в банках как правило хватает в среднем на 1-1,5 месяца.
Да пусть хоть на 7 дней, если сработает штатный механизм защиты от xid wraparound
> а теперь то это зачем
Это Вы спросите у OpenAI которые используют 50 реплик пг чтобы осилить такие нагрузки. Кажется, что у тех же банков поток нагрузки будет поменьше в масштабе страны, хотя если приложение написано как кусок г... там ничего уже не поможет.
Спасибо за статью. Остается ждать когда-же что-то появится в опенсорсе и можно будет пощупать, пока в репах Тантор на github очень скудно.
P.S. На самом деле у всех довольно скудно, PostgresPro тоже ушла в закрытие кода многих продуктов, взять хотя бы probackup. В общем типовой кровавый энтерпрайз и вендор лок, только вид сбоку.
Это реальный кейс клиента когда 1 сервер с PostgreSQL должен держать тысячи соединений? Или это тестовый кейс, для того чтобы показать узкое место PostgreSQL?
Может просто не делать так? Не создавать тысяч соединений? Сделать 50 реплик и распределить соединения по ним?
Насколько я понял, проблема проявляется при высокой параллельности и при использовании множества SAVEPOINT. Но я не понял опять же - это реальный кейс у клиента или это искусственно созданная ситуация чтобы показать проблемное место PostgreSQL? Если это реально кейс клиента, то у скольких клиентов проявляется такая проблема? Если из 1000 клиентов она проявляется у 1 клиента, то это 0,1% и возникает вопрос - а так ли это важно? Ну я про то, что нужно вложиться в решение этой проблемы на уровне устранения в коде PostgreSQL, не проще ли устранить проблему иными способами у этого 1-го клиента, например изменением архитектуры приложения или модели работы с СУБД и тп?
Это как с 64-х битным счетчиком транзакций, все упарываются внедряя его в коммерческие форки PostgreSQL, но никто не показывает статистику - у скольких клиентов существует такая проблема с переполнением счетчика? У 2-3 клиентов из 10000? Или у 150 клиентов из 10000? А сколько из этих клиентов не смогли воспользоваться штатным механизмом PostgreSQL чтобы предотвратить переполнение счетчика транзакций и кластер реально встал колом? Данных нет. Никто их не показывает, зато все пишут что у них 64-х битный счетчик транзакций, это мега-важный плюс покупки коммерческого форка PostgreSQL. Так и хочется сказать - Вы серьезно?
Это конечно чудесно, все изменения между версиями лить одним комитом. Разработка начала нулевых. Гит это просто свалка кода
Мало информации о плане - плохо, много - плохо.
Неплохо, пару советов, если позволите
1) Скриншоты панели бы в репу, для наглядности.
2) Пароль админа желательно бы чтобы был уникальным, а не стандартным или как минимум при первом входе обязательно был запрос на его смену.
Интересно, а как они исправили баги в ClientHello если PR запросы в одном случае закрыт и не влит в мастер, во втором он висит открытым и тоже не влит в мастер?
Получается публичная репа это просто фикция и в реальности сборки делаются на основе какой-то закрытой репы к которой у сообщества нет доступа? Тогда где гарантия, что готовые сборки соответствуют кодовой базе публичной репы? Нигде, опять же получается.
MR в кодовую базу телеграм с исправлением багов не приняли. Один точно закрыли, в десктоп. Второй в ios пока висит открытым, но кажется и его не примут. С андроид непонятно, да и мне лично он не интересен.
Все это прекрасно, но что толку от навороченного mtproxy если тспу блокируют к нему доступ? А создатели телеграм как бы и не собираются исправлять баги в реализации tls чтобы скрыться от тспу.
Круг замкнулся, проще использовать сами знаете какие решения и не мучиться с mtproxy
Нейронка глюканула наверно)
Сколько уже лет эта тема движется? 5 или 7? Когда же наконец будет хоть какой-то сдвиг в ваниле? Я честно говоря уже потерял все треды где там патч с поддержкой 64-битного счетчика пытаются ребейзить до текущей версии пг и оттестировать. 2 человека что-ли над этим работают, кажется что это очень мало и даже в 20-й версии пг мы не увидим полностью 64-битный счетчик во всех местах.
Кажется что это классический подход используемый в Serverless, но со своими прихватами в виде Parquet
Что-то типа Neon Serverless Postgres или иных решений на базе Neon
Оркестратор в офф репе https://github.com/github/orchestrator не развивается и не будет развиваться больше, репа в архивном режиме, так что я бы не стал его использовать.
Есть форк от Percona https://github.com/percona/orchestrator но и он официально не является сопровождаемым, но там хотя бы исправляют хоть какие-то найденный ошибки.
Спасибо, всегда приятно читать технические аспекты реализации!
glib нет на любом утюге, а postgres там нужно запускать
А где же видос как она ездит?
Если Вы не умеете готовить мускуль и правильно писать запросы, делать DDL, то и на постгрес Вы словите такого же рода проблемы просто в другом месте. С любой БД можно подскользнуться и больно упасть если не вникать в тонкости и нюансы работы базы. Речь конечно про хайлоад, а не пет-проект с 10 посетителями в час.