Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Обновление PostgreSQL с устранением уязвимостей"	+/–
Сообщение от opennews (??), 14-Ноя-20, 11:25
Сформированы корректирующие обновления для всех поддерживаемых веток 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
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Обновление PostgreSQL с устранением уязвимостей"	+6 +/–
Сообщение от InuYasha (??), 14-Ноя-20, 11:25
Патченный слоник - хороший слоник.
Ответить | Правка | Наверх | Cообщить модератору

2. Скрыто модератором	–33 +/–
Сообщение от Аноним (2), 14-Ноя-20, 11:36
Решетo, а вообще везде MySQL стандарт.
Ответить | Правка | Наверх | Cообщить модератору

	3. Скрыто модератором	+4 +/–
	Сообщение от Иваня (?), 14-Ноя-20, 12:00
	MySQL тож решэто :(
	Ответить | Правка | Наверх | Cообщить модератору

	4. Скрыто модератором	+6 +/–
	Сообщение от zo0M (ok), 14-Ноя-20, 12:02
	толсто
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	6. Скрыто модератором	+3 +/–
	Сообщение от Catwoolfii (ok), 14-Ноя-20, 12:41
	для простых сайтиков - да, стандарт
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	8. Скрыто модератором	+3 +/–
	Сообщение от Lex (??), 14-Ноя-20, 12:48
	С ростом доли SSD в хостинге, для простых сайтов стандартом вновь может стать SQLite
	Ответить | Правка | Наверх | Cообщить модератору

	10. Скрыто модератором	–7 +/–
	Сообщение от Аноним (2), 14-Ноя-20, 13:06
	А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	13. Скрыто модератором	+1 +/–
	Сообщение от Catwoolfii (ok), 14-Ноя-20, 13:30
	Может быть потому, что популярные CMS поддерживают только mysql?
	Ответить | Правка | Наверх | Cообщить модератору

	18. Скрыто модератором	+/–
	Сообщение от And (??), 14-Ноя-20, 14:07
	Хм... Вы где вообще нашли MySql. Maria DB давно уже вместо него. :) Старый у Вас софт.
	Ответить | Правка | Наверх | Cообщить модератору

	15. Скрыто модератором	+2 +/–
	Сообщение от Аноним (15), 14-Ноя-20, 13:53
	> А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг? Наверное, потому что вы работаете только с очень простыми сайтами. За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин, у которого один покупатель в неделю", MySQL практически не встречается.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	20. Скрыто модератором	–1 +/–
	Сообщение от Lex (??), 14-Ноя-20, 14:34
	Очень даже встречается Не встречается он, обычно, в конторах( если уж зашла речь о торговле ) с десятками-сотнями-тысячами торговых точек и эпической системой, связывающей все это + закупки + аналитику итп. Но там из реальных вариантов или MSSQL, или Postgres, поскольку базы реально огромны
	Ответить | Правка | Наверх | Cообщить модератору

	30. Скрыто модератором	+/–
	Сообщение от пох. (?), 14-Ноя-20, 22:24
	> За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин, > у которого один покупатель в неделю", MySQL практически не встречается. встречается, встречается - у тех кто в свое время либо наелись "vacuum full; reindex", либо вовремя избежали встречи. Ну и с ha всерьез столкнулись. С травмами. Другое дело что это тот, второй стул, и ассортимент на нем, за пределами шитхостингов за три копейки, тоже весьма так себе. За ms или oracle рабовладельцы могут не хотеть платить, sqlite надо уметь готовить, с этим у современных "разработчиков" плохо.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

5. "Обновление PostgreSQL с устранением уязвимостей"	+4 +/–
Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 12:37
13 как падала на создании GIST индексов по триграмам, так и 13.1 ровно в том же месте падает :-( Остаемся на 12, она стабильная..
Ответить | Правка | Наверх | Cообщить модератору

	7. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Аноним (7), 14-Ноя-20, 12:46
	Число нехорошее, по-видимому :|
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Аанон (?), 14-Ноя-20, 12:50
	А багу зарегали?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	26. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 19:54
	> А багу зарегали? Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 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 уже падает главный процесс.. внятной ошибки не выводится.. ждем репортов.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от мяя (?), 14-Ноя-20, 23:40
	А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при падении навыков нет?
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 00:30
	> А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при > падении навыков нет? Есть, равно как и понимание что без отладочной инфы (а почему-то в pgdg стали собирать без debuginfo) и потом траты кучи времени на объяснение разработчикам, где как и что реального результата не получится. А это время мне, увы, не оплачивается.. Так что я лучше займусь задачами, которые нужны тому, кто мне платит :)
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Аноним (35), 15-Ноя-20, 00:58
	В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно поставить и у вас появятся отладочные символы в отладчике.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 18:02
	> В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно > поставить и у вас появятся отладочные символы в отладчике. Это в редхате. Да, они раньше паковали debuginfo.. К 9 например.. но почему-то к последним версиям перестали. Видимо, багрепортов больше не ждут.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Мелкий (?), 16-Ноя-20, 18:40
	> Это в редхате. Да, они раньше паковали debuginfo.. К 9 например.. Devrim (сопровождающий rpm репы) решил в отдельный репозиторий вынести https://yum.postgresql.org/news/devel-rpms-require-a-new-rep.../ В deb репозитории на месте. postgresql-12-dbgsym в частности. (какое-то время назад, впрочем, назывались *-dbg вместо dbgsym, возможно вас это запутало)
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 17-Ноя-20, 23:46
	>> Это в редхате. Да, они раньше паковали 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, работающего немного постабильнее.. Там и проапгрейдимся. Спасибо всем, кто мотивировал меня таки залезть в трейс. Хоть он и почти пустой из-за кривости рук сборщиков пакетов.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 18-Ноя-20, 00:03
	>[оверквотинг удален] >  /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, нужно оторвать руки :)
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Мелкий (?), 18-Ноя-20, 00:11
	Ну, к rpm репе действительно есть вопросы... А даже вот такой backtrace на самом деле уже интересен. gtrgm_alloc сам по себе только в pg13 и появился. Вполне бы уже могли натолкнуть в нужную сторону. 13.2 будет 11 февраля, через полгода 13.3 уже.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	45. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от тральшик (?), 16-Ноя-20, 07:33
	http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres... не оно?
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	49. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 17-Ноя-20, 23:48
	> http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres... > не оно? нет ) Оно оказалось тут https://download.postgresql.org/pub/repos/yum/debug/13/redha.../ но собрано неправильно и нужный дебагинфо к -contrib пакету не соответствует самому пакету, см. комментарий выше. Ну да ладно.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от JL2001 (ok), 15-Ноя-20, 00:16
	>> А багу зарегали? > Нет. Как ни пытался, не смог сделать минимальное воспроизведение сообщите хотяб в таком виде, возможно, вам там напишут или волшебные флаги или способ диагностики или помогут с минимизацией или созданием абстрактного набора данных для теста
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	36. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Anon_noXX (?), 15-Ноя-20, 04:47
	a self-compiled Postgres 12.1 I could successfully ... running a default-configured packaged version of postgres 12 for ubuntu 16.04 Может, оно? А может быть jit? Или ФС - zfs.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Anon_noXX (?), 15-Ноя-20, 04:54
	Впрочем, я погорячился, товарищи из Core Team проблему подтверждают. Сорри.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Anon_noXX (?), 15-Ноя-20, 04:57
	И опять я не прав, переписка-то 2019 годом заканчивается :)
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от JL2001 (ok), 15-Ноя-20, 15:36
	> И опять я не прав, переписка-то 2019 годом заканчивается :) так ворвитесь в тред и апните топик может у них не на ком воспроизвести зы: а вы пробовали на копии бд заменить боевые данные рандомными значениями и воспроизвести на этом уже не секретном инстансе? зыы: после экспорта+импорт чере sql воспроизводится? тоесть не зависит от раскладки данных по секторам? зыыы: ну и на другую фс точно так же можно попробовать перетащить на какой-нить тестовой машине или вообще через mount loop образа фс, а не на реальной фс
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Обновление PostgreSQL с устранением уязвимостей"	+1 +/–
	Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 18:01
	>> И опять я не прав, переписка-то 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 образа фс, > а не на реальной фс От этого не зависит.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Аноним (19), 14-Ноя-20, 14:33
	номер репорта есть ?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	47. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от DEF (?), 17-Ноя-20, 20:53
	Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет. Его контакты легко гуглятся.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	50. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 17-Ноя-20, 23:49
	> Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет. > Его контакты легко гуглятся. Спасибо. Уже кто-то зарепортил аналогичный баг (см. комментарий выше) и сделали экспериментальный патч.. может в следующем релизе поправят и падать перестанет.
	Ответить | Правка | Наверх | Cообщить модератору

11. "Обновление PostgreSQL с устранением уязвимостей"	–6 +/–
Сообщение от Аноним (2), 14-Ноя-20, 13:10
Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор
Ответить | Правка | Наверх | Cообщить модератору

	12. "Обновление PostgreSQL с устранением уязвимостей"	–9 +/–
	Сообщение от Аноним (12), 14-Ноя-20, 13:28
	Потому что сабж плохо управляем в целом, да и производительность из-за постоянной необходимости вакуума (ну, если не хочешь хранить гигабайты ненужных удалённых строк) у него так себе.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Обновление PostgreSQL с устранением уязвимостей"	+1 +/–
	Сообщение от Аноним (19), 14-Ноя-20, 15:24
	это было до 8.1, когда не было автовакуума. сейчас все пучком даже на больших нагрузках
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Обновление PostgreSQL с устранением уязвимостей"	–4 +/–
	Сообщение от Аноним (14), 14-Ноя-20, 13:38
	Не заговор, а не востребован.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	16. "Обновление PostgreSQL с устранением уязвимостей"	+3 +/–
	Сообщение от Аноним (15), 14-Ноя-20, 13:55
	> Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор Потому что хостинг - это самый дешевый вариант, для сайтов с крайне малой нагрузкой. Что-то более-менее заметное живет на VPS, дедике и колокации.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	22. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от BSA (?), 14-Ноя-20, 15:57
	VPS из той же ниши, что и хостинг. Серьезную нагрузку не тянет, а если загрузить на сколько тянет, то хостер будет возмущаться, что ты слишком много ресурсов потребляешь.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Аноним (28), 14-Ноя-20, 21:34
	В случае с ДО там топовые конфигурации получали значительно больше ресурсов и меньше соседей с шиткоинами. Линода вроде меньше оверселлила. Возмущений что-то не припомню, зато помню как в зависимости от поведения соседей менялась производительность.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Обновление PostgreSQL с устранением уязвимостей"	+1 +/–
	Сообщение от лютый жабби__ (?), 14-Ноя-20, 21:36
	>VPS из той же ниши, что и хостинг. бред. у хетцнеров даже самый просто vps за 3 евро просто реактивный, что по процу, что по IO. на многих задачах оно просто рвёт парумилионные железные серверы (более старые и без SSD) )
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	17. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Иван (??), 14-Ноя-20, 13:56
	Например? У меня ровно наоборот. Забыл когда последний раз видел mysql/mariadb.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	24. "Обновление PostgreSQL с устранением уязвимостей"	+3 +/–
	Сообщение от Аноним (24), 14-Ноя-20, 17:24
	Что вы имеете в виду под хостингом? AWS - постгрес есть. Google Cloud - постгрес есть. Azure - постгрес есть.  DigitalOcean - постгрес есть. Yandex.Cloud - постгрес есть. Mail.ru cloud solutions - постгрес есть.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	44. "Обновление PostgreSQL с устранением уязвимостей"	+1 +/–
	Сообщение от Аноним (44), 15-Ноя-20, 23:42
	Если раньше под сайт достаточно было виртуального хоста + фтп + MySQL, то теперь надо отдельная виртуальная машина в облаке с операционкой в докере с постгресом, с операционной в докер с нджинксом, с операционной в докер с питоном, с кубернетесом, что бы запускать этот зоопарк докеров, не забываем про еластик стек, графану, прометеус, что там ещё молодёжно?
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Обновление PostgreSQL с устранением уязвимостей"	–1 +/–
	Сообщение от zzz (??), 14-Ноя-20, 18:01
	Потому что мамкины вебмастера не умеют в что-то сложнее SELECT * FROM?
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	27. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Casm (??), 14-Ноя-20, 20:33
	Gitlab, например, только с postgresql работает
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	53. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от ptr128 (?), 21-Ноя-20, 15:33
	Если MySQL достаточно, то почему бы и нет? А вот для DW MySQL мало пригоден, тогда как PostgreSQL отлично с многотерабайтными БД справляется. Хоть и не без костылей, как принято в OpenSource )
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

23. "Обновление PostgreSQL с устранением уязвимостей"	–8 +/–
Сообщение от Ilya Indigo (ok), 14-Ноя-20, 16:25
Оказывается VACUUM теперь не только к тормознутости приводит (сам git-подобный движок хранения, которому он нужен), но ещё и к проблеме с безопасностью.
Ответить | Правка | Наверх | Cообщить модератору

	40. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Аноним (40), 15-Ноя-20, 15:13
	Работает не трожь
	Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором	–3 +/–
Сообщение от Аноним (40), 15-Ноя-20, 15:10
К базам просто прикасаться то страшно, а тут еще и обновить. А если все упадет? Лучше уж проприетарщина, там дыры если и есть их сложнее искать.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема