Re: Безопасность chroot
Hello!
On Sunday 30 August 2009 21:55:39 Victor Wagner wrote:
> Э, это что в postgres за последние 10 лет сломали? Что где-то между 95 и
> 99-м отломали time travel как несовместимый с жизнью production
> database, это я помню. А вот чтобы что-то после ломали - не помню. Хотя
> я его не только использую, но временами еще и патчу.
>
> По-моему, там могли отламываться только какие-то кривые 3rd-party
> патчи. Которые в upstream не были приняты как раз из-за кривизны и
> несовместимости с уже имеющимся в HEAD направлением развития.
Сломали преобразование типов данных - вот такая или подобная конструкция
возвращала ошибку в дебиановской версии постгреса 8.3 (ленни):
select 1='1'::int;
Баг-репорт на это дело висел, патчи вышли, но сомневаюсь, что в апдейты
для ленни включили.
> Вообще, честно сказать, я не знаю НИ ОДНОГО opensource проекта со столь
> же чистым и удобочитаемым кодом, как postgres.
После включения в движок полнотекстового поиска, поддержки xml и прочих
свистелок посгрес стремительно догоняет openoffice и kde. За гигабайты shared
memory я тоже спасибо разработчикам не скажу. При объединении более чем
10-ти таблиц в отчетах или использовании функциональных индексов
планировщик сходит с ума, почти так же, как в "мохнатой" версии 7.4.x. В итоге
вроде бы возможностей много, но при их использовании производительности
скатывается до неприлично низкой, что делает использование проблематичным.
И что на нескольких "тяжелых" запросах (обрабатывающих выборки размером
более, чем имеющаяся на сервере RAM) убивает сервер свопом, несмотря на
ограничения в конфиге, не радует.
Что касается качественного кода - см. эскулайт. Кстати, многие проекты перенес
с постгреса на эскулайт, причем те же самые запросы стали работать на порядки
быстрее. На постгресе выборка в 5 гиг на серваке с 1 Гб ОЗУ требовала более часа
для получения статистического отчета, причем при запуске второго похожего
запроса сервер "умирал", на эскулайте та же выборка строится 1 минуту... Да,
многих функций не хватало в эскулайте, потребовалось их дописать, зато
получил быструю СУБД и без "дури" в выполнении запросов.
Лет 7 назад постгрес из открытых СУБД был вне конкуренции. Но сегодня, на мой
взгляд, ничего хорошего из себя не представляет - возможно, разработчики
сменились или их приоритеты...
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: