Сформированы (https://www.postgresql.org/about/news/1939/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 11.3 (https://www.postgresql.org/docs/current/static/release-11-3....), 10.8 (https://www.postgresql.org/docs/current/static/release-10-8....), 9.6.13 (http://www.postgresql.org/docs/current/static/release-9-6-13...), 9.5.17 (http://www.postgresql.org/docs/current/static/release-9-5-17...) и 9.4.22 (http://www.postgresql.org/docs/current/static/release-9-4-22...), в которых представлена порция исправлений ошибок. Выпуск обновлений для ветки 9.4 продлится (http://www.postgresql.org/support/versioning/) до декабря 2019 г., 9.5 до января 2021 г., 9.6 - до сентября 2021 года, 10 - до октября 2022 года, 11 - до ноября 2023 года.В новых версиях исправлено более 60 ошибок и устранено четыре уязвимости:
- Две уязвимости (CVE-2019-10127, CVE-2019-10128) специфичны для уплатформы Windows и проявляются в инсталляторах от компаний EnterpriseDB и BigSQL, которые не выставляли надлежащих прав доступа на каталог с данными, что позволяло любому непривилегированному пользователю Windows инициировать выполнение кода на уровне сервиса PostgreSQL.
- Уязвимость CVE-2019-10129 проявляется в PostgreSQL 11 и позволяет пользователю прочитать произвольные области памяти серверного процесса через отправку специально оформленного запроса INSERT к партицированной таблице.
- Уязвимость CVE-2019-10130 позволяет прочитать значения записей, к которым ограничен доступ.Из исправленных ошибок можно отметить повреждение каталога при выполнении "ALTER TABLE" над партицированной таблицей, крах сервера при возникновении ошибки при попытке сохранения курсора между подтверждениями транзакции, проблемы с производительностью при откате транзакций, охватывающих большое число таблиц, отсутствие поддержи выражения "CREATE TABLE IF NOT EXISTS .. AS EXECUTE ..", утечки памяти.
URL: https://www.postgresql.org/about/news/1939/
Новость: https://www.opennet.me/opennews/art.shtml?num=50660
Объясните мне, почему столько веток у него? А также вопрос к тем, кто давно юзает и разбирается, какие преимущества и в чем существенные отличия от MySQL/MariaDB? Благодарю заранее.
Посмотрите темку в нете почему Uber ушел с постгреса на мускл.
А вообще подбешивают таблицы большими буквами и т.д.
В посгресе дофига плагинов. Есть говновакуум.. в общем пока не попробуешь под свои задачи - непонтяно, что лучше он или MySQL. Я за последний.
Тащем-то в мыскле тоже наличествует свой вакуум, который время от времени тоже надо применять на движках сложнее MyISA.
Штэ?
OPTIMIZE TABLE table_name;Не знал? Фанбои мыскля еще много чего про свой фетиш не знают. И прямую ложь про "нет вакуума" двадцать лет всем в уши дуют.
Какой ещё MyISAM? Все давно используют InnoDB. А для тех кто всё же поленился пройти по указанным материалам от Uber-a и смежным докладам, даже русскоязычных докладчиков... У InnoDB табличный движок более хорошо приспособлен для определённых типов операций и постоен на UNDO таблице в которую помещаются данные колонок обновлённых записей на которые ещё есть открытые транзакции. Как следствие этого при закрытии транзакций и репликации данные можно просто удолить из этой специальной таблицы без порождения фрагментации данных в таблице на диске.Движок PostgreSQL копирует обновлённую запись, а старую помечает, как удалённую. Новые транзакции пускаются на новую запись, а старая завершает обслуживание уже начатых транзакций. Как следствие, старые записи надо вычищать для чего и служит механизм VACUUM. Но при больших нагрузках и частых записях возникает проблема, так как процесс VACUUM более ресурсоёмкий чем чистка отдельной таблицы UNDO. Так же как следствие подобной организации работы с данными является разница в качестве работы репликации в этих базах и по сути невозможность master-master репликации для PostgreSQL. Если в 11 версии ничего не поменялось. Не смотрел её ещё.
In a nutshell...
Спасибо посмеялся. InnoDB сразу данные удаляет? Только недавно делал на базе с ним чистку, так после OPTIMIZE TABLE база похудела на 50 гиг. Причём делался он ну очень, очень долго.
> Спасибо посмеялся. InnoDB сразу данные удаляет? Только недавно делал на базе с
> ним чистку, так после OPTIMIZE TABLE база похудела на 50 гиг.
> Причём делался он ну очень, очень долго.Я не говорил о моментальном удалении данных. Я говорил о том, что механизм UNDO более дешёвый с точки зрения производительности чем механизм VACUUM при котором надо сканить таблицы и что-то делать с фрагментацией данных.
> механизм UNDO более дешёвый с точки зрения производительности чем механизм VACUUMСильно зависит от нагрузок.
UNDO в стиле Oracle, грубо говоря, удваивает объем выполняемой записи в журнал - потому что его надо тоже защищать REDO.
>Oracle, грубо говоря, удваивает объем выполняемой записи в журналНу если грубо говоря, то учетверяет. Пишем журнал->undo->журнал->обновленную запись.
В PG 3 : журнал->новая->пометка старой
У Oracle выигрыш в использовании места (а соответственно быстрее full scan) на частых update, но и chained rows как следствие.
> В PG 3 : журнал->новая->пометка старойО! Капитан, уточните, какие из трёх указанных "running service" (или как бы это назвать -- запущенный сервис с кешом (("мастер", реплики вообще не интересны--)) в озу) таки-да _не_ пишет на диск _вне чекпоинтов_.
Мне всегда это было интересно, но всё никак не могу разобраться до конца.
Есть "оптимистичное" предположение, что не пишутся при указанных условиях 2 из 3-ёх. Но есть смутные сомнения, что условия не все или не те... Требуется помощь очевидных войск... ?
> Есть "оптимистичное" предположение,Да. Оптимистично только журнал. Но это при условии что нагрузка нерегулярная и иногда дает покурить. А если постоянная и на максимуме, как в свое время в Сбере, то в какой-то момент времени выясняется, что терабайт памяти пишется на диск не моментально, а если запаниковать, то его еще из журналов восстанавливать надо, что тоже не ускоряет процесс.
>>Oracle, грубо говоря, удваивает объем выполняемой записи в журнал
> Ну если грубо говоря, то учетверяет. Пишем журнал->undo->журнал->обновленную запись.Удваивает *запись в журнал* - т.е. синхронную запись, которая напрямую влияет на скорость выполнения.
Вся остальная запись асинхронная, и влияние её косвенное (увеличивает количество IOPS, но при этом хорошо параллелится и не блокирует дальнейшие действия приложения).
> В PG 3 : журнал->новая->пометка старой
> У Oracle выигрыш в использовании места (а соответственно быстрее full scan)
> на частых update, но и chained rows как следствие.Алгоритмы Oracle сокращают фрагментацию основного табличного пространства ценой двойной фиксации изменений: в основное табличное пространство и в UNDO.
Тут такое дело, VACUUM в PG дело добровольное. И если его не дергать, то он ни на что не влияет. И получается так, что у мыскля с его UNDO производительность только съедается впустую. И да, если в мыскле применить аналог vacuum'а, то таблицы лочатся намертво.
Причём таблица блокируется полностью
>Посмотрите темку в нете почему Uber ушел с постгреса на мускл.Если не просто посмотреть, а ещё и почитать, то можно увидеть, что Uber, фактически, реализует файловую систему поверх SQL, для чего MySQL внезапно подходит значительно лучше именно благодаря своей примитивности.
Так скакать с ветки на ветку не все умеют одинаково хорошо.PS: ушло в репозиторий sisyphus_e2k ещё утром 9 мая.
А почему у них должны возникать проблемы? Оно настолько безоглядно разрабатывается, что даже в рамках девятой версии аж три ветки приходится поддерживать? Это базы данных-то? Офигеть.
До 10-й версии мажорными считались релизы 9.x минорными 9.x.y, как уже сказали, между мажорными версиями нет бинарной совместимости файлов, и весьма разный набор фич.Начиная с 10-й версии схему привели к общепринятому виду, убрав лишнюю цифру из версии.
Непонятно что вас смущает в LTS, это же стандартная практика для серьёзного софта.
Потому что это секьюрити-фиксы. И потому что в постгресе нет бинарной совместимости между разными мажорными версиями.
Его главное отличие от MariaDB, MySQL, Percona - он один. Все чаще наблюдаю картину, когда компоненты работающие в рамках одного проекта ранее спокойно жили вместе на одной БД на мыскле, теперь могут начинать конфликтовать из-за того, что кто-то хочет фичи от MariaDB а кому-то подавай ортодоксальный MySQL от оракакеля. И чем дальше, тем разломы между фактически одной и той же СУБД только расширяются и углубляются. Что тут скажешь, фанбои мыскля сами выбрали свой путь страдания.
Мне кажется, что Оракл специально реализует фичи из MariaDB с другим синтаксисом, чтобы усложнить миграцию.
Да это как-то однопенисно. Вот то, что они уже пилят две разные несовместимые клиентские библиотеки, вот это п....ц и Израиль.
ну так он вызван изначальной глупостью - пытаться вместо чистого форка сделать drop-in replacement. В результате совместимость все равно поломана, но вот удержать на одном хосте две разные - теперь неприемлемый геморрой (слава виртуалочкам, что уже низачем и не нужно)
> какие преимущества и в чем существенные отличия от MySQL/MariaDB?В рамках данной дискуссии ваш вопрос относится скорее к категории религиозных.
Преимущества и недостатки имеют все перечисленные системы. Для админа локалхоста/конторы до 1000 юзеров вообще никакой разницы, кроме той, что MySQL везде, где заявлена/требуется БД всунут по умолчанию, а для использования вместо него PostgreSQL придется приложить некие минимальные дополнительные усилия.
бросьте, вот только что приходил товарисч, взгромоздивший на постгрез zabbix. В конторе до 1000 и никто его не заставлял.
(ну да, ну да - с его бесконечными поштучными insert, запросами where ... in ( ) , и "housekeeping" с delete where in - что ведет к интересным последствиям для постргезовой уродливой системы хранения, с ее "vacuum ненужен, ненужен, ненужнен!" )А фэйловерили они ее побайтовым копированием, ага.
Не завидую пришедшему ему на смену.
> почему столько веток у него?Разрабам не лень их поддерживать, а может их спонсируют организации использующие сабж.
> какие преимущества и в чем существенные отличия от MySQL/MariaDB?Отличий множество! Это инструменты для разных целей!
Для WEB-разработки (Как правило подобные вопросы интересуют в основном их, да и сам я интересовался для этого) ничем не лучше - только хуже!
Связка MariaDB + redis + Sphinx - уделывает по производительности чистый сабж!
А если СУБД используется по локалхосту через сокет единственным пользователем (стандартный сценарий WEB-приложений), то MariaDB и быстрее и функциональнее, благодаря возможности использовать разные движки (InnoDB и ROCKSDB) под разные задачи.
В 12-й релиз запилили API для новых типов storage engine, новые сторажи завезут скорее всего не раньше 13-го релиза (т.е. минимум года через 1.5).
> В 12-й релиз запилили API для новых типов storage engine, новые сторажи
> завезут скорее всего не раньше 13-го релиза (т.е. минимум года через
> 1.5).То есть ещё очень не скоро и ещё не известно как эти новые типы себя поведут и сколько времени нужно на их отладку!
> ничем не лучше - только хуже!Тю.
Вот у меня есть таблица users, в которой есть email и поле deleted_at, которое не null, если пользователь удален.
Я хочу сделать unique index на email, но только для тех юзеров, которые не удалены.
В постгресе я делаю индекс на email where deleted_at is null.
А как в мыскле? Да, есть костыль с persistent virtual column и индексом на него, но - в каком синтаксисе, MariaDB или Oracle mysql?Или, скажем, у меня есть timestamp и я хочу сделать индекс только по году и месяцу и только для тех записей, где стоит определенный статус.
Или, скажем, я хочу сделать PRIMARY KEY uuid. Как, binary(16) и поворачиваем байтики? Очень удобно.
Или, скажем, у меня есть таблица со структурой, где большинство полей null, и я хочу эффективно искать по любой их комбинации. Или JSON, по внутрянке которого я хочу искать так же эффективно. В постгресе у меня есть GIN и GIST на выбор. В мыскле... мммм... ну, я могу формировать для каждого поля псевдо-слово типа _FIELD_A_IS_123_ и искать фуллтекстом, лол.
Да можно долго перечислять.
>> ничем не лучше - только хуже!
> Тю.
> Вот у меня есть таблица users, в которой есть email и поле
> deleted_at, которое не null, если пользователь удален.
> Я хочу сделать unique index на email, но только для тех юзеров,
> которые не удалены.
> В постгресе я делаю индекс на email where deleted_at is null.
> А как в мыскле? Да, есть костыль с persistent virtual column и
> индексом на него, но - в каком синтаксисе, MariaDB или Oracle
> mysql?Текстовые поля вообще не нужно индексировать без крайней на то необходимости, даже для уникальности.
В вашем примере будет просто каша из многих не уникальных email.
В любом случае, нужно сообщить пользователю, что email-занят, так что проверять уникальеность Нужно вручную и индекс UNIQUE тут не нужен!> Или, скажем, у меня есть timestamp и я хочу сделать индекс только
> по году и месяцу и только для тех записей, где стоит
> определенный статус.И что мешает индекс на timestamp и статус указать?
> Или, скажем, я хочу сделать PRIMARY KEY uuid. Как, binary(16) и поворачиваем
> байтики? Очень удобно.Ни понял ни что это ни в чём удобство. Примери у меня всегда только числа!
> Или, скажем, у меня есть таблица со структурой, где большинство полей null,
> и я хочу эффективно искать по любой их комбинации. Или JSON,
> по внутрянке которого я хочу искать так же эффективно. В постгресе
> у меня есть GIN и GIST на выбор. В мыскле... мммм...Снова не понял в чём тут проблема искать нулы?
> ну, я могу формировать для каждого поля псевдо-слово типа _FIELD_A_IS_123_ и
> искать фуллтекстом, лол.И снова не понял зачем это нужно и что это даёт?
Если нужен полнотекстовый поиск, то сфинксом сабж по производительности и рядом не стоял!> Да можно долго перечислять.
Нет, Ваших высранных из пальцев примеров мне больше не нужно.
Ууууу...Скажите, а где вы работаете?
Ну так, чтобы случайно туда не обратиться.
Единственное в чем выигрывает Mysql и его подобия это простота администрирования. В PostgreSQL при помощи обилия ручек вы можете подогнать под свой workload. По итогу в тех проектах где админ говорит ну оно вот так работает, проще выбрать mysql, там где нет возможности впендюривать костыли и настраивать БД под задачу проще выбрать mysql, где программисты хотят просто хранить данные проще выбрать mysql и сказать ну вот оно так работает. Если вы инженер то должны понимать что забивать гвозди чугунной сковородкой гораздо удобнее чем микроскопом, но это не значит что микроскоп гавно. Просто вы используете его не по назначению.
> Единственное в чем выигрывает Mysql и его подобия это простота
> администрирования. В PostgreSQL при помощи обилия ручек вы можете подогнать под
> свой workload. По итогу в тех проектах где админ говорит
> ну оно вот так работает, проще выбрать mysql, там где
> нет возможности впендюривать костыли и настраивать БД под задачу проще выбрать
> mysql, где программисты хотят просто хранить данные проще выбрать mysql
> и сказать ну вот оно так работает. Если вы инженер
> то должны понимать что забивать гвозди чугунной сковородкой гораздо удобнее чем
> микроскопом, но это не значит что микроскоп гавно. Просто вы используете
> его не по назначению.MySQL также можно подогнать под нужды и настроить там что угодно, хоть кэш отключить, хоть дать подсказки оптимизатору запросов, хоть свой движок написать. Но Вы считаете, что каждый пользователь сабжа занимается его тонкой настройкой?
Впендюривание костылей, да ещё и на этапе разработки, когда не понятен характер нагрузки...
Нет уж, нормальный, в моём понимании, программист на такое не пойдёт!
Это сабж, со своим вакуумом, "вот так работает", которому программную реапликацию совсем недавно завезли. Судя по вашим упоминаниям костылей, самостоятельно она нормально и не работает.
В MySQL можно выбрать и движок, под конкрерную задачу, и тонко настроить выделение памяти, и просто надёжную настроить репликацию (master-slave) и управлять ей. При этом координально изменить работу СУБД Вы всё равно не можете и для максимальной эффективности, Вы должны понимать как она работает в том числе и как работает PostgreSQL!
Я не говорил что сабж какащка. Я говорил что он и MariaDB созданы для разных целей, и для вэб-приложений, где единственный пользователь через сокет и не нужны вообще хранимые процедуры, и есть возможность применить MariaDB+Redis+Sphinx сабж будет хуже, как по быстродействию, так и по надёжности, так и по сложности проектирования и сопровождения.
Простота администрирования - в базовых случаях да. А тонкий тюнинг innodb - это отдельная уличная магия.
если тебе понадобился тонкий тюнинг innodb - посгрез на этом же железе на той же задаче уже давно бы лопнул или необратимо бы крэшнул базу.Во всяком случае, если решать ее в лоб, игнорируя оптимизатор-планировщик и особенности хранения. Чего, понятное дело, ни один разработчик не любит, поскольку вся эта оптимизация для того и придумана, чтобы не заморачиваться особенностями конкретной субд.
> В PostgreSQL при помощи обилия ручек вы можетекое-как добиться почти такой же производительности и надежности, как у mysql из коробки - если повезет с workload.
Поправил, не благодари.
> ... и надежности, как у mysqlЭто в смысле когда база мыскля вдруг тупо впадает в задумчивость и оживает только после прохода
mysqlcheck -r -f ?
>какие преимущества и в чем существенные отличия от MySQL/MariaDB?Классика же, ну: https://grimoire.ca/mysql/choose-something-else
> почему столько веток у него?потому что более энтерпрайзен, это как Oracle 11, 12, 2018...
10й postgres уже готов для продакшена, порекомендовать можете ?
Юзаем 11, проблем особых не испытываем.
Тоже 11 в проде
10-й в яндексе используютhttps://cloud.yandex.ru/docs/managed-postgresql/qa/postgresql
в гугле 9.6 и 11.1
Давно готов. Уже и на 11-м полет нормальный.
И cтоит ли ради всех фич логической репликации апдейтиться с 9.6 до 10.8 ?
Если эти фичи вам нужны, то стоит. Если не нужны - то не стоит.
Если все устраивает на текущей ветке, то смысле дергаться до осень 21-го года нет никакого.
Ради параллельных вычислений на 11 стоит
Где-то плачет один Аноним755...
Ребят, а какие линуксовые среды разработки есть годные под него типа [PL]SQL Developer на Оракле?
vim, emacs
ed жеж, почти edge
В общем, загуглил, но хотел узнать чем здешние люди пользуются для разработки на PL.
> но хотел узнать чем здешние люди пользуются для разработки на PL.- А чем вы гладите тонкое женское белье?
- ??? ... А чем ВЫ гладите тонкое женское белье?
- Я глажу тонкое женское белье рукой...
Насчет оркела не знаю, но и для постгреса, и для мыскля мне более чем хватает database-плагина в IntelliJ IDEA. Оно есть и в виде отдельного продукта, DataGrip называется, попробуйте, может, там и с Ораклом все хорошо. Поддержка по крайней мере заявлена.Да это все, конечно, проприетарщина, но раз у вас Оракл, думаю, не должно смущать.