Кажется на пгдее кто то из яндекса говорил что мол не все так прекрасно и иногда бекап может быть не совсем корректен

бакапы надо всегда проверять, например сторадж покараптил данные, где вы хранили бакап

в этом был спитч

ммм

бэкапы нужно проверять всегда, мы, например, поднимаем базу с бэкапа и делаем COPY * TO /dev/null

бэкапы нужно проверять всегда, мы, например, поднимаем базу с бэкапа и делаем COPY * TO /dev/null

в этом случае, никто не гарантирует что индексы у вас в бакапе - норм :)

в этом случае, никто не гарантирует что индексы у вас в бакапе - норм :)

индексы в бекапе?

а ну если с wal и прочим

индексы не так страшно, ты можешь reindex сделать если что

конечно, но reindex - однопоточный :)

и требует времени в случае обнаружения

ресторить в несколько потоков ))

памяти не хватит :)

ну не в 10 потоков же

хотя на 8 потоков мне хватало и 8ГБ

Извечный вопрос о бекапах, тут заметил что у одних товарищей "неконсистентный" бекап, после после разворачивания требуется некоторое время на рекавери, и у них нет WAL архива. Именно отсутствие вал-архива приводит к подобным эффектам ? или я что-то не правильно понимаю ?

а какую ошибку база говорит? откуда понятно, что бэкап неконсистентный? и бэкап делался с --xlog или нет?

c --xlog конечно

на счет ошибки непонятно, я вроде прочекал всё работает... но была жалоба пока не могу понять на что.

Более того, по умолчанию

сделал ext4 defaults - дефолтные параметры, пока что так

сделал ext4 defaults - дефолтные параметры, пока что так

Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old. //by man mount

commit 0a1c01c9477602ee8b44548a9405b2c1d587b5a2 Author: Matthew Garrett <mjg@redhat.com> Date: Thu Mar 26 17:53:14 2009 +0000 Make relatime default Change the default behaviour of the kernel to use relatime for all filesystems. This can be overridden with the "strictatime" mount option. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ну знач не нужно указывать ниче, в дефолте relatime самое нормальноеф?

его, кстати, видно в /proc/self/mounts

а nobarrier не буду делать, пока затыка в io нету, мало ли, на надежность вроде влияет

Друзья, быстрый вопрос. PQreset убивает сессию? Соответственно и все временные объекты, верно? Или сессия остается жива, а просто переподнимается канал до сервера?

тоесть сортировка будет делаться не на основе конкретной системной локали, а на основе http://site.icu-project.org/

этот пакет регистронезависимость как-нибудь может сделать?

Снова здравствуйте. Есть ли способ из бекапа таблицы в формате custom отресторить в таблицу с другим именем, но с теми же полями, индексами и прочим?

Снова здравствуйте. Есть ли способ из бекапа таблицы в формате custom отресторить в таблицу с другим именем, но с теми же полями, индексами и прочим?

самый простой подход - востановить в другую схему :)

потом ренейм

Снова здравствуйте. Есть ли способ из бекапа таблицы в формате custom отресторить в таблицу с другим именем, но с теми же полями, индексами и прочим?

Или отресторить в SQL, и ручками поменять

самый простой подход - востановить в другую схему :)

а как указать схему для pg_restore?

Или отресторить в SQL, и ручками поменять

слишком большой размер

этот пакет регистронезависимость как-нибудь может сделать?

этот пакет - основа utf-8, как вы используете регистронезависимость?

а как указать схему для pg_restore?

можно пользуна создать и схему с названием = имя пользователя

сравнение без upper\under нужно

по дефолту будут создаваться в его схеме, как в оракле

сравнение без учета регистра

по дефолту будут создаваться в его схеме, как в оракле

а потом от суперузера перенести в public можно?

угу, rename

щас попробуем, благодарю

этот пакет - основа utf-8, как вы используете регистронезависимость?

ну вот кроме citext другого способа нет? может локаль какая-то регистронезависимая существует

Из пакетов. Однозначно.

не подскажешь, почему постгрес желательно из пакетов ставить, а не с исходников ?

не подскажешь, почему постгрес желательно из пакетов ставить, а не с исходников ?

Я думаю, что вообще всё надо ставить из пакетов, не только постгрес. Чтобы систему не захламлять.

как она захламляется?

типо выбрать свою папку установки, значит захламить?

да

типо выбрать свою папку установки, значит захламить?

Да, как уже выше ответили.

а мне не нравится. что папку установки нельзя выбрать /oracle /postgresql было бы красиво

а мне не нравится. что папку установки нельзя выбрать /oracle /postgresql было бы красиво

Нарисуйте свой пакет - в чём проблема-то?

никакой, просто я не знал, что из пакета жалетельно ставить, поэтому спросил почему

как она захламляется?

Никак. Если можешь сопровождать, то ничего страшного.

а мне не нравится. что папку установки нельзя выбрать /oracle /postgresql было бы красиво

? Что есть папка установки в linux )

не знаю

Ну скомпилите вы из исходников -ну раскидаете бинарники по всей ФС - а потом решите обновиться - как весь этот хлам удалять?

Хотите задавать папку установки - есть пакеты вроде http://www.enterprisedb.com/products-services-training/pgdownload Где все можно задать

Но это тоже хрень та еще

есть http://www.pathname.com/fhs/ что бы не было всякого "красиво"

там в стандартах описано где должен лежать постгрес?

Ну скомпилите вы из исходников -ну раскидаете бинарники по всей ФС - а потом решите обновиться - как весь этот хлам удалять?

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

там в стандартах описано где должен лежать постгрес?

Где должны лежать изменяемые данные

там описано где должно лежать все

при обновление пакета постгреса он те же файлы перезатирает видимо?

Но это тоже хрень та еще

Аргументируйте, пжлст

скорее "правильней" сделать свою сборку и свой пакет, и не переживать

Аргументируйте, пжлст

Когда я ей пользовался - версия 9.2 - удаления тоже небыло

Я ею пользуюсь с 9.1, удаление есть

Она очень удобна

ERROR: S client not available

Обновлять так, вообще лафа

Ну я ее предложил как альтернативу пакетам. Просто я постепенно понял -что пакеты еще удобнее

а пакетами удобно обновлять если нет доступа к репозитоиям?

а пакетами удобно обновлять если нет доступа к репозитоиям?

Свой репо сделай.

а пакетами удобно обновлять если нет доступа к репозитоиям?

Скачай нужные пакеты

И поставь

Подумал тут - у пути enterprisedb есть одно приемущество перед пакетами

Если поставлять в составе инталяторов - так удобнее

Вот именно из-за удобства я и люблю сборки энтерпрайза

Мне пакеты удобнее

Если бы постгреспро такой же инсталлятор забацали, то перешел бы на их сборки

Причем я предпочитаю deb. Но это скорее дело привычки.

а я ставил с сайта postgresql пакеты rpm

Если бы постгреспро такой же инсталлятор забацали, то перешел бы на их сборки

Согласен - должны быть разные варианты - это называется "клиентоориентированность"

Я собираю из исходников. 1) Аргументы такие: unix-админы могут спокойно обновлять ось и я не боюсь, что мне сломают БД. 2) Приложение разрабатывается на конкретной версии БД. Шанс, что у вас в приложении что-то сломается после обновления тоже достаточно высок. 3) Я могу собрать софт с теми опциями, которые мне нужны. В разных дистрах ментейнеры собирают по разному. Возможно, делают патчи специфичные для дистра. А так у меня ванильный постгрес и минимум зависимостей. А в чём была бы польза кроме вреда от постгреса из репы, я даже придумать не могу.

беда в криво-скрипто-апдейтах :) debian по умолчанию рестартит при обновлении минорных версий

ну вот, тут написали что лучше из пакета, а выходит я даже зря из пакета ставил

Я собираю из исходников. 1) Аргументы такие: unix-админы могут спокойно обновлять ось и я не боюсь, что мне сломают БД. 2) Приложение разрабатывается на конкретной версии БД. Шанс, что у вас в приложении что-то сломается после обновления тоже достаточно высок. 3) Я могу собрать софт с теми опциями, которые мне нужны. В разных дистрах ментейнеры собирают по разному. Возможно, делают патчи специфичные для дистра. А так у меня ванильный постгрес и минимум зависимостей. А в чём была бы польза кроме вреда от постгреса из репы, я даже придумать не могу.

Но бывает же, необходимость обновиться?

Но бывает же, необходимость обновиться?

а что мешает? :) если у вас 100500 баз в кедах - то суйти в пакеты или в контейнеры

Вот эта автоматика меня и пугает. Так я новую версию в каталок /opt/pgsql-$ver собрал, БД опустил, симлинк /opt/pgsql-current перекинул, БД поднял. И все под контролем.

а в суровом энтерпрайзе с минимальным временем простоя пакеты для db не нужны, они вносят лишние флюктуации

Ну опять же пакеты будут - хоть и ты мэйнтейнер сам. А не на голой ос исходники make install делать

Ну опять же пакеты будут - хоть и ты мэйнтейнер сам. А не на голой ос исходники make install делать

Согласен. Но только - если ментейнер - ты сам.

а в суровом энтерпрайзе с минимальным временем простоя пакеты для db не нужны, они вносят лишние флюктуации

В суровом ентерпрайзе есть термин: эксплуатация.

нет, тебе нужно будет стать специалистом по /debian /rpm-spec

я говорил про пакеты с deb.postgresql.org, которые рестартят pg без надобности

тыже возмешь основу с них

и наступишь на все грабли

например с оболочкой cluster start

который считает что кластер не стартанул, если он не успел логи накатить за 60 секунд

это все для ноутбука збс

а для реальной эксплуатации кривопакеты - это боль