The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

"Обновление 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.me/opennews/art.shtml?num=54088

Ответить | Правка | Cообщить модератору

Оглавление

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


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

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

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

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

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

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

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

13. Скрыто модератором  +1 +/
Сообщение от Catwoolfii (ok), 14-Ноя-20, 13:30 
Ответить | Правка | Наверх | Cообщить модератору

18. Скрыто модератором  +/
Сообщение от And (??), 14-Ноя-20, 14:07 
Ответить | Правка | Наверх | Cообщить модератору

15. Скрыто модератором  +2 +/
Сообщение от Аноним (15), 14-Ноя-20, 13:53 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

20. Скрыто модератором  –1 +/
Сообщение от Lex (??), 14-Ноя-20, 14:34 
Ответить | Правка | Наверх | Cообщить модератору

30. Скрыто модератором  +/
Сообщение от пох. (?), 14-Ноя-20, 22:24 
Ответить | Правка | К родителю #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 +/
Сообщение от Анонимemail (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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру