Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 13.1, 12.5, 11.10, 10.15, 9.6.20 и 9.5.24. Обновления для ветки 9.5 будут формироваться до февраля 2021 г., 9.6 - до ноября 2021 года, 10 - до ноября 2022 года, 11 - до ноября 2023 года, 12 - до ноября 2024 года, 13 до ноября 2025 года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54088
Патченный слоник - хороший слоник.
Решетo, а вообще везде MySQL стандарт.
MySQL тож решэто :(
толсто
для простых сайтиков - да, стандарт
С ростом доли SSD в хостинге, для простых сайтов стандартом вновь может стать SQLite
А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг?
Может быть потому, что популярные CMS поддерживают только mysql?
Хм... Вы где вообще нашли MySql. Maria DB давно уже вместо него. :)
Старый у Вас софт.
> А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг?Наверное, потому что вы работаете только с очень простыми сайтами.
За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин, у которого один покупатель в неделю", MySQL практически не встречается.
Очень даже встречается
Не встречается он, обычно, в конторах( если уж зашла речь о торговле ) с десятками-сотнями-тысячами торговых точек и эпической системой, связывающей все это + закупки + аналитику итп. Но там из реальных вариантов или MSSQL, или Postgres, поскольку базы реально огромны
> За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин,
> у которого один покупатель в неделю", MySQL практически не встречается.встречается, встречается - у тех кто в свое время либо наелись "vacuum full; reindex", либо вовремя избежали встречи. Ну и с ha всерьез столкнулись. С травмами.
Другое дело что это тот, второй стул, и ассортимент на нем, за пределами шитхостингов за три копейки, тоже весьма так себе.
За ms или oracle рабовладельцы могут не хотеть платить, sqlite надо уметь готовить, с этим у современных "разработчиков" плохо.
13 как падала на создании GIST индексов по триграмам, так и 13.1 ровно в том же месте падает :-(Остаемся на 12, она стабильная..
Число нехорошее, по-видимому :|
А багу зарегали?
> А багу зарегали?Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 10000 строк падает, на таблице 5000 строк (любая половина этих 10000) - нет. Репорт с реальными данными сделать не могу (да и им нужно предсказуемое воспроизведение).
Нашел только что падает особенно резво при попытке указать fillfactor отличный от дефолтного. Причем с некоторыми падает, с некоторыми нет.
На табличке на 100000 строк падает и без указания fillfactor. Чем больше табличка, тем резвее падает. Падает весь сервер, натурально, без каких-либо внятных сообщений.
Очень надеялся, что в 13.1 что-то станет лучше, но увы. Думаю, мало кто использует gist индексы... В первых релизах 12 (12.0/12.1) тоже было падение на этой же табличке ровно на этом же индексе :)) Но там падало иначе, в wal writer, при этом выводилось некое сообщение об ошибке, в итоге кто-то зарепортил такую же багу (https://www.postgresql.org/message-id/16162-45d21b7b6c1a3105...) и начиная с 12.2 исправили и получилось проапгрейдиться на 12.
А вот 13 уже падает главный процесс.. внятной ошибки не выводится.. ждем репортов.
А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при падении навыков нет?
> А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при
> падении навыков нет?Есть, равно как и понимание что без отладочной инфы (а почему-то в pgdg стали собирать без debuginfo) и потом траты кучи времени на объяснение разработчикам, где как и что реального результата не получится. А это время мне, увы, не оплачивается.. Так что я лучше займусь задачами, которые нужны тому, кто мне платит :)
В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно поставить и у вас появятся отладочные символы в отладчике.
> В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно
> поставить и у вас появятся отладочные символы в отладчике.Это в редхате. Да, они раньше паковали debuginfo.. К 9 например.. но почему-то к последним версиям перестали. Видимо, багрепортов больше не ждут.
> Это в редхате. Да, они раньше паковали debuginfo.. К 9 например..Devrim (сопровождающий rpm репы) решил в отдельный репозиторий вынести https://yum.postgresql.org/news/devel-rpms-require-a-new-rep.../
В deb репозитории на месте. postgresql-12-dbgsym в частности. (какое-то время назад, впрочем, назывались *-dbg вместо dbgsym, возможно вас это запутало)
>> Это в редхате. Да, они раньше паковали debuginfo.. К 9 например..
> Devrim (сопровождающий rpm репы) решил в отдельный репозиторий вынести https://yum.postgresql.org/news/devel-rpms-require-a-new-rep.../Это тут не причем, но
> В deb репозитории на месте. postgresql-12-dbgsym в частности. (какое-то время назад, впрочем,
> назывались *-dbg вместо dbgsym, возможно вас это запутало)Мало собрать debuginfo :) Надо собрать их к нужным пакетам! Что мейнтейнеры постгреса сделать не сумели.
warning: the debug information found in "/usr/lib/debug//usr/pgsql-13/lib/pg_trgm.so-13.1-1PGDG.rhel8.x86_64.debug" does not match "/usr/pgsql-13/lib/pg_trgm.so" (CRC mismatch).
Missing separate debuginfo for /usr/pgsql-13/lib/pg_trgm.so
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
Нужные пакеты, разумеется, стоят:$ rpm -qf /usr/lib/debug//usr/pgsql-13/lib/pg_trgm.so-13.1-1PGDG.rhel8.x86_64.debug /usr/pgsql-13/lib/pg_trgm.so
postgresql13-contrib-debuginfo-13.1-1PGDG.rhel8.x86_64
postgresql13-contrib-13.1-1PGDG.rhel8.x86_64$ dnf debuginfo-install --enablerepo=pgdg13-updates-debuginfo /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
подключение репозитория epel-modular-debuginfo
подключение репозитория epel-debuginfo
Последняя проверка окончания срока действия метаданных: 0:12:07 назад, Вт 17 ноя 2020 15:11:26.
Нет совпадений для аргумента: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
Ошибка: Не удалось найти совпадение: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debugопаньки...
А падение как раз в pg_trgm.so. И состояния переменных трейса не получить.. Увы.
Core was generated by `postgres: postgres message_db_dev [local] CREATE INDEX '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:304
304 movq -8(%rsi,%rdx), %rcx
(gdb) where
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:304
#1 0x00007fbb71fe1d2b in gtrgm_alloc () from /usr/pgsql-13/lib/pg_trgm.so
#2 0x00007fbb71fe328e in gtrgm_picksplit () from /usr/pgsql-13/lib/pg_trgm.so
#3 0x00000000008d1ace in FunctionCall2Coll ()
#4 0x00000000004b174e in gistSplitByKey ()
#5 0x00000000004b1b4f in gistSplitByKey ()
#6 0x00000000004a8dc3 in gistSplit ()
#7 0x00000000004a918b in gistplacetopage ()
#8 0x00000000004a9cb8 in gistinserttuples ()
#9 0x00000000004aa10a in gistdoinsert ()
#10 0x00000000004ab80e in gistBuildCallback ()
#11 0x00000000004ccf0d in heapam_index_build_range_scan ()
#12 0x00000000004abe25 in gistbuild ()
#13 0x0000000000541887 in index_build ()
#14 0x0000000000542da0 in index_create ()Т.е. gtrgm_alloc делает memmove в неинициализированные области памяти..
Но не все потеряно - я не смог, другие смогли. Очень похожий наконец-то зарепортили в IRC и пять дней назад выкатили патч (я не проверял, но по идее это то, что надо). Вот тут: https://www.postgresql-archive.org/Strange-GiST-logic-leadin...
Жаль, в релиз не вошел. Ну ничего, PG 12 и 12.1 тоже были с критическим багом GIST индексов.. ситуация с 13 просто повторение. Ждем через пол-годика 13.2, работающего немного постабильнее.. Там и проапгрейдимся.
Спасибо всем, кто мотивировал меня таки залезть в трейс. Хоть он и почти пустой из-за кривости рук сборщиков пакетов.
>[оверквотинг удален]
> /usr/pgsql-13/lib/pg_trgm.so
> postgresql13-contrib-debuginfo-13.1-1PGDG.rhel8.x86_64
> postgresql13-contrib-13.1-1PGDG.rhel8.x86_64
> $ dnf debuginfo-install --enablerepo=pgdg13-updates-debuginfo /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
> подключение репозитория epel-modular-debuginfo
> подключение репозитория epel-debuginfo
> Последняя проверка окончания срока действия метаданных: 0:12:07 назад, Вт 17 ноя 2020
> 15:11:26.
> Нет совпадений для аргумента: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
> Ошибка: Не удалось найти совпадение: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debugОх. Посыпаю голову пеплом.. я понял, в чем проблема. Дебагинфо в теории на месте, но.. все-таки кривые репозитории!
Суть проблемы: postgresql13 для 8.2 и для 8.3 создан с одним номером сборки. Они не обновляют друг друга.. тк они по сути идентичны. Но фактически они разные. На данной системе PG13 был проагпрейжен до 13.1 когда был 8.2, а дебагинфо поставлен когда был 8.3. В репе это разные каталоги с чуть разными, но идентичными версиями сборок. Они идентичны в плане работы, но не идентичны в плане debuginfo. Причем с тем, как сделана их репа, dnf не может увидеть правильный дебагинфо через debuginfo-install, т.к. там фильтр по релизам.
Тому, кто собрал версию для более нового дистрибутива без инкремента чего-либо, на что смотрит rpm, нужно оторвать руки :)
Ну, к rpm репе действительно есть вопросы...А даже вот такой backtrace на самом деле уже интересен. gtrgm_alloc сам по себе только в pg13 и появился. Вполне бы уже могли натолкнуть в нужную сторону.
13.2 будет 11 февраля, через полгода 13.3 уже.
http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres... не оно?
> http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres...
> не оно?нет )
Оно оказалось тут https://download.postgresql.org/pub/repos/yum/debug/13/redha.../
но собрано неправильно и нужный дебагинфо к -contrib пакету не соответствует самому пакету, см. комментарий выше. Ну да ладно.
>> А багу зарегали?
> Нет. Как ни пытался, не смог сделать минимальное воспроизведениесообщите хотяб в таком виде, возможно, вам там напишут или волшебные флаги или способ диагностики или помогут с минимизацией или созданием абстрактного набора данных для теста
a self-compiled Postgres 12.1I could successfully ... running a default-configured packaged version of postgres 12 for ubuntu 16.04
Может, оно? А может быть jit? Или ФС - zfs.
Впрочем, я погорячился, товарищи из Core Team проблему подтверждают. Сорри.
И опять я не прав, переписка-то 2019 годом заканчивается :)
> И опять я не прав, переписка-то 2019 годом заканчивается :)так ворвитесь в тред и апните топик
может у них не на ком воспроизвестизы: а вы пробовали на копии бд заменить боевые данные рандомными значениями и воспроизвести на этом уже не секретном инстансе?
зыы: после экспорта+импорт чере sql воспроизводится? тоесть не зависит от раскладки данных по секторам?
зыыы: ну и на другую фс точно так же можно попробовать перетащить на какой-нить тестовой машине или вообще через mount loop образа фс, а не на реальной фс
>> И опять я не прав, переписка-то 2019 годом заканчивается :)
> так ворвитесь в тред и апните топик
> может у них не на ком воспроизвестиДа нет! Там бага была другая совсем. Кто-то доопотимизировался при записи WAL в PG12 :) И индекс, работавший в 10 и 11 сломался. Ту багу давно поправили. Просто падало ровно на этом индексе этой же таблицы. Но падало в wal writer; при этом основной процесс постгреса успевал выдать нечто внятное перед полным паднием. А сейчас падает вообще все сразу и без внятной ошибки.
> зы: а вы пробовали на копии бд заменить боевые данные рандомными значениями
> и воспроизвести на этом уже не секретном инстансе?Это и есть на копии. Это даже не продакшен, я воспроизвожу багу при попытке сделать dump+restore из 12 в 13 на дев или тестовых БД. Более того, дело касается ровно одной таблицы, другие не нужны.
> зыы: после экспорта+импорт чере sql воспроизводится? тоесть не зависит от раскладки данных
> по секторам?Воспроизводится как угодно. От раскладки не зависит :)
Я могу сделать create table xxx as select * from src_table limit 10000 offset <любое значение>;
И следующий create index test_ind on xxx (gist на (timestamp + text gist_trgm_opts)) на эту новую xxx всегда свалит сервер.> зыыы: ну и на другую фс точно так же можно попробовать перетащить
> на какой-нить тестовой машине или вообще через mount loop образа фс,
> а не на реальной фсОт этого не зависит.
номер репорта есть ?
Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет. Его контакты легко гуглятся.
> Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет.
> Его контакты легко гуглятся.Спасибо. Уже кто-то зарепортил аналогичный баг (см. комментарий выше) и сделали экспериментальный патч.. может в следующем релизе поправят и падать перестанет.
Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор
Потому что сабж плохо управляем в целом, да и производительность из-за постоянной необходимости вакуума (ну, если не хочешь хранить гигабайты ненужных удалённых строк) у него так себе.
это было до 8.1, когда не было автовакуума. сейчас все пучком даже на больших нагрузках
Не заговор, а не востребован.
> Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговорПотому что хостинг - это самый дешевый вариант, для сайтов с крайне малой нагрузкой.
Что-то более-менее заметное живет на VPS, дедике и колокации.
VPS из той же ниши, что и хостинг. Серьезную нагрузку не тянет, а если загрузить на сколько тянет, то хостер будет возмущаться, что ты слишком много ресурсов потребляешь.
В случае с ДО там топовые конфигурации получали значительно больше ресурсов и меньше соседей с шиткоинами. Линода вроде меньше оверселлила. Возмущений что-то не припомню, зато помню как в зависимости от поведения соседей менялась производительность.
>VPS из той же ниши, что и хостинг.бред. у хетцнеров даже самый просто vps за 3 евро просто реактивный, что по процу, что по IO.
на многих задачах оно просто рвёт парумилионные железные серверы (более старые и без SSD) )
Например?
У меня ровно наоборот. Забыл когда последний раз видел mysql/mariadb.
Что вы имеете в виду под хостингом?
AWS - постгрес есть. Google Cloud - постгрес есть. Azure - постгрес есть. DigitalOcean - постгрес есть. Yandex.Cloud - постгрес есть. Mail.ru cloud solutions - постгрес есть.
Если раньше под сайт достаточно было виртуального хоста + фтп + MySQL, то теперь надо отдельная виртуальная машина в облаке с операционкой в докере с постгресом, с операционной в докер с нджинксом, с операционной в докер с питоном, с кубернетесом, что бы запускать этот зоопарк докеров, не забываем про еластик стек, графану, прометеус, что там ещё молодёжно?
Потому что мамкины вебмастера не умеют в что-то сложнее SELECT * FROM?
Gitlab, например, только с postgresql работает
Если MySQL достаточно, то почему бы и нет?
А вот для DW MySQL мало пригоден, тогда как PostgreSQL отлично с многотерабайтными БД справляется. Хоть и не без костылей, как принято в OpenSource )
Оказывается VACUUM теперь не только к тормознутости приводит (сам git-подобный движок хранения, которому он нужен), но ещё и к проблеме с безопасностью.
Работает не трожь
К базам просто прикасаться то страшно, а тут еще и обновить. А если все упадет? Лучше уж проприетарщина, там дыры если и есть их сложнее искать.