Postgresql 8.2 released

Эх, добавили бы в PostgreSQL jobs-ы. И для меня был бы полный комплект.

К стати а ведь вчера была эта новость, но ее удалили через пару минут! http://www.linux.org.ru/profile/I3rain/view-message.jsp?msgid=1683354#1683730

Блин все не как не могу привыкнуть к сылкам на лоре

http://www.linux.org.ru/jump-message.jsp?msgid=1683354#1683730

>>> Подробности

Здесь пресс-релиз на русском языке: http://www.postgresql.org/about/press/presskit82.html.ru

Наверное в подробности лучше давать эту ссылку:
http://www.postgresql.org/about/press/presskit82.html.ru

мля.. только 6 часов назад перешел на 8.1.5, и какого спрашивается?

Добавил перевод в текст новости.

я вот тож хотел одну базу с 7ки перевести, но вот лень было... Видимо не зря :)

>Добавил перевод в текст новости.

:good: :)

порадуемся за Постргре!

Какие Jobs имеются ввиду? Если выполнение различных SQL-запросов и процедур (PL/pgSQL, SQL, Java, Python, Perl, PHP, C etc.) по рассписанию , то стоит посмотреть в сторону PGAgent - лежит в контрибсах в стандартной поставке.

>Стоит отметить заявленное увеличение производительности на 20%

Чего то я по сравнению 8.1.5 не увидел такого.

Зачем джобы?

Есть PGagent (для регулярных действий), есть отложенные транзакции (для ведения журнала событий)

В 8.2.0 локализация хромает, имхо на продакшн рановато, надо подождать 8.2.1

недотерпел :)

Ну блин, а я всё на mysql, надо все сайты перевести на постгрии, не оракла, но очень вкусная база, блин.... слюни текут, как будет время... начнуться бессоные ночи, по переносу сайтов на новую базу =)

> В 8.2.0 локализация хромает, имхо на продакшн рановато, надо подождать 8.2.1

Можно чуть подробнее?

Локализация чего именно (сообщения, какие-нибудь индексы в UTF-8, etc)и как именно хромает?

K sojaleniu, ia vas rasstrou... Localizovannye month and day names zaviazany na fily perevoda ( '.po'), kotorye dlia russkogo iazyka ne obnovlialis' dlia pg8.2. Ia tolko chto otpravil patch s obnovlennym perevodom, tak chto skoree vsego v 8.2.1 budet vse pokazyvat'... K sojaleniu dlia 8.2.0 uje slishkom pozdno... (c) sql.ru

Transaction log file switching now also happens automatically during pg_stop_backup(). This ensures that all transaction log files needed for recovery can be archived immediately.

класно

> Localizovannye month and day names zaviazany na fily perevoda ( '.po')

Меня это нисколько не расстраивает.

Известны ли какие-то проблемы с локализацией, проявляющиеся с LC_MESSAGES=en_US?

>K sojaleniu, ia vas rasstrou... Localizovannye month and day names zaviazany na fily perevoda ( '.po'), kotorye dlia russkogo iazyka ne obnovlialis' dlia pg8.2. Ia tolko chto otpravil patch s obnovlennym perevodom, tak chto skoree vsego v 8.2.1 budet vse pokazyvat'... K sojaleniu dlia 8.2.0 uje slishkom pozdno... (c) sql.ru

Локализованные сообщения с датой появились только в 8.2, так что старые программы, я думаю, будут работать нормально.

Отличная новость ... есть повод испить чего нибудь .. )))

>> Есть PGagent (для регулярных действий), есть отложенные транзакции (для ведения журнала событий)

можно подробнее про отложенные? где их/про них искать?

угу будут, тем не менее в release notes было заявлено что "Allow to_char() to print localized month and day names", но не работает (хотя, возможно, просто имелось ввиду, что появилась возможность выдавать локализованные месяц и день). к тому же, сюдя по указанному сообщению, .po-файл не обновился для 8.2, т.е. утилиты в составе дистрибутива порадуют смесью русско-английских сообщений, что несколько портит впечатление от релиза.

Inverted Indexes уже есть, Bitmap Indexes будут в 8.3 (мне лично это все не нужно ;) - так что, летом уже сравняемся по фичастости с Ораклом?! :)

>Ну блин, а я всё на mysql, надо все сайты перевести на постгрии, не >оракла, но очень вкусная база, блин.... слюни текут, как будет время... >начнуться бессоные ночи, по переносу сайтов на новую базу =)

И вырванные годы при каждом последующем апгрейде базы.

> И вырванные годы при каждом последующем апгрейде базы.

А можно по подробнее, уважаемый анонимус?

Я конечно переживаю по поводу перехода с 8.1 на 8.2. Но переходы 8.1.0->8.1.1->8.1.2->...8.1.5 прошли абсолютно гладко: configure с теми же параметрами make make install /etc/rc.d/rc.postgres restart (- задержка секунд на 15)

И всё. Версия обновлена. А в чём проблемы-то?

> Я конечно переживаю по поводу перехода с 8.1 на 8.2. Но переходы 8.1.0->8.1.1->8.1.2->...8.1.5 прошли абсолютно гладко: configure с теми же параметрами make make install /etc/rc.d/rc.postgres restart (- задержка секунд на 15)

Переход на 8.2 конечно не будет таким гладким - придется делать dump/restore - структура кластера баз данных изменилась.

Upgrade с семерки на 8.1 тоде без проблем прошел - данные, конечно, пришлось переносить через дамп, но оно того стоило.

>И всё. Версия обновлена. А в чём проблемы-то?

Он видимо имеет в виду pg_dump/pg_restore в случае, если база большая, хотя pg_dump | bzip2 на лету могут спасти ситуацию ;)

Отличная новость.. PostgreSQL становиться всё более привлекательнее..

Уже make идет. Ща пляски с бубном по переносу базы начнутся :)

Фигли там переносить? Скриптик забабахал (который) дампит все базы и ресторит их, и никаких плясок с бубном :)

У меня пляски заключаются в следующем: 1) Патчить tsearch2 до восприятия CP1251. 2) В базе есть триггеры, которые по on insert делают вставки в другие таблицы. При этом в дампе данные из этих таблиц уже есть. В общем, часть триггеров приходится отключать или менять порядок вставки.

>Фигли там переносить? Скриптик забабахал (который) дампит все базы и ресторит их, и никаких плясок с бубном :)

На кой скриптик?! А pg_dumpall зачем?

> 2) В базе есть триггеры, которые по on insert делают вставки в другие таблицы. При этом в дампе данные из этих таблиц уже есть. В общем, часть триггеров приходится отключать или менять порядок вставки.

По моему там есть в pg_dump пунктик-параметр, который отключит все триггеры на время восстановления. Так что это не проблема, почитайте документацию.

>2) В базе есть триггеры, которые по on insert делают вставки в другие таблицы. При этом в дампе данные из этих таблиц уже есть. В общем, часть триггеров приходится отключать или менять порядок вставки.

--disable-triggers

Ну и чем оно лучше Oracle XE???

А разве Oracle XE уже отдают совсем без ограничений (размер базы, кол-во процев, кол-во узверей и проч.)?

>>Ну и чем оно лучше Oracle XE???

>Так, Sony Online Entertainment объявила [SOE05] об инвестировании 1.5 млн. USD в Enterprise DB для перехода с Oracle на PostgreSQL 8.1.

Да, нтересно почему? :)

"По мере того как мы добавляем больше возможностей и услуг поддержки, проблема с данными становится все больше, - говорит Герман. – Наши потребности и их стоимость масштабируются синхронно, и стало ясно, что пришла пора подумать над альтернативными вариантами". Он не сообщил, как много серверов баз данных будут переведены на новую платформу, или вообще о характере потребностей компании в обработке данных. Sony Online договорилась приобрести "очень большое число лицензий [EnterpriseDB] прямо сейчас, и собирается приобретать их в очень большом количестве в будущем". Как отметил Герман, "переход только начался, и Sony Online будет продолжать использовать ПО от Oracle в обозримом будущем. Мы надеемся, что по мере масштабирования наших потребностей мы будем внедрять все больше и больше приобретенного инструментария EnterpriseDB".

http://oracle.ukrsat.com/news/oracle1679.html

>А разве Oracle XE уже отдают совсем без ограничений (размер базы, кол-во процев, кол-во узверей и проч.)?

Ограничения по кол-ву юзеров нет, если не ошибаюсь... Всё остальное если ограничивает то это уже говорит про крупную организацию которая вполне может себе купить...

p.s. В Oracle XE можно испольховать удалённые БД т.е. строить кластер...

>Всё остальное если ограничивает то это уже говорит про крупную организацию

размер базы в 2гига это для крупной организации???!!! что же тогда для мелкой ну ооооочень мелкой организации?

> Всё остальное если ограничивает то это уже говорит про крупную
> организацию которая вполне может себе купить...

Зачем покупать (читай тратить деньги) если функционала и производительности PostgreSQL хватает?

Крупные компании тоже умеют деньги считать.

смотрел я на enterprisedb где-то пол года назад, база интересная но сильно недотягивала до oracle7 (92 год), там небыло пакетов, sys_refcursor, connect by prior, матвью и слишком много прочего ... короче с выходом oracle xe совсем смысл в enterprisedb теряется. стартануть можно и с oracle xe, а дальше $5K за проц не такие уж большие деньги.

Minotaurus.

ограничения oracle xe: 4Gb размер БД, 1 проц и кажется 2Gb RAM

Minotaurus.

>ограничения oracle xe: 4Gb размер БД, 1 проц и кажется 2Gb RAM

а когда подходишь к этим пределам система автоматически связывается с главным офисом и оттуда тебе по факсу присылают счет. :)))

>>ограничения oracle xe: 4Gb размер БД, 1 проц и кажется 2Gb RAM

>а когда подходишь к этим пределам система автоматически связывается с главным офисом и оттуда тебе по факсу присылают счет. :)))

Больше она просто использовать не будет.

То есть мне на мой четырех Operton'овый можгл установить на выбор:

Oracle XE - $0 - но работать будет только 1 проц да и 4 GB - это данный на квартал.
Oracle 10g - 4 x $5K ~ $20K - все пучком, но! сервак с 16G RAM стоил $28K ...
PostgreSQL 8.* - $0 - все пучком, все что нужно - умеет .... а на сЪЫканомленные $20K возьму еще железа!

В больших корпорациях разница еще сувствительнее ... Тут недавно лицезировали оракул на HP Superdome дык пол-лимона как с куста :)

Вот и считайте :)

>мне на мой четырех Operton'овый можгл

Интересно - чено я этим хотел сказать? :)

Слепой метод рулит...

Хорошая новость!