Бухайте уже а не работайте

Бухайте уже а не работайте

А мне нравится. У меня творческий запой.

Утра.

Может Кому интересно будет

https://www.youtube.com/watch?v=h_GdEaF1Ymc&index=1&list=PLaFqU3KCWw6KzGwUubZm-9-vKsi6vh5qC

https://www.youtube.com/watch?v=jGOkSerUPw4&feature=youtu.be

крайний курс был в Ростове-на-Дону 14-17 апреля, еще видо не вылажили его

https://www.youtube.com/watch?v=jGOkSerUPw4&feature=youtu.be

Спасибо )

лучше смотреть сейчас идущий dba2

там больше полезного, и страшного.

выходит одна серия в неделю на 2 часа )

так что можно смотреть как онгоинг )

ага, он попродвинутей

спасибо постгреспро

А ктонить с Тольятти тут есть?

Никита ! )

лучше смотреть сейчас идущий dba2

ссылку, же!

)))

там же на ютубе, среди видео постгресспро можно найти плейлист

все те же лица :)

Ахой )

Присоединюсь, к вопросу. Коль, как ты видишь себе этот мониторинг?

Про мониторинг надо Dmitry Vasiliev пинать.

Бэкэнд полит основные характеристики или если получится записывает события по их появлению. Александр Коротков в своем блоге показал разные waitы. Складывает в таблички или fdw. А внеший мониторинг просто забирают собранную инфу, если нужно.

Сдаюсь. Пееречитал документацию про localization, отгуглил, и всё равно остались вопросы. 1. Хочу просто UTF-8 и сортировку его же. Что писать в LC_CTYPE и LC_COLLATE? А есть универсальная вроде utf8_unicode_ci в MySQL? 2. Почему базу с не SQL_ASCII кодировкой нужно создавать из template0? Честно говоря, разделу про templateX нужна дополнительная брошюра или там может есть какая-то дополнительная глава. Но вроде все слова понятны, а общий текст "папа, ты с кем сейчас разговаривал"? 3. Есть некий initdb, который там "кластер" инициализирует. А после инициализации параметры можно поменять? А как посмотреть? Вот ту же кодировку

Initdb не просто инициализирует он его создаёт. Там честно говоря жесть творится.

Initdb не просто инициализирует он его создаёт. Там честно говоря жесть творится.

А поменять это как-то можно? Или pgdump, rm -rf, initdb, pgdump?

Что "это"? Да rm -rf вполне помогает...

Что "это"? Да rm -rf вполне помогает...

Я хочу дефолтный энкодинг поменять

Ааа

ПРоще пересоздать

Pg_dump может спасти.

С указанием энкодинга

Да

ну т.е. можно не менять, потому что если я базам явно его задаю, то вроде это ни на что не влияет?

Иначе он и инкодинг сдампит.

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

Или да?

"Хочу просто UTF-8 и сортировку его же. Что писать в LC_CTYPE и LC_COLLATE? А есть универсальная вроде utf8_unicode_ci в MySQL?" а с этим как? Я чего-то совсем завис. Проставил везде C.UTF-8. Но я не уверен

Просто локейшен используется при построении индексов, на лету это менять нельзя. :(

Надо пересоздавать бд.

Иначе могут быть сюрпризы.

ну так а что мешает автоматизировать сей процесс? меняешь настройки - создаётся новая и старая, меняются местами?

ну то есть чтобы пользователь не пугался такого страшного "убить базу" :)

увести в maintance и сделать это

Если у вас терабайтная бд, это не тривиальная задача. Короче админы пусть и автоматизируют. :)

Просто локейшен используется при построении индексов, на лету это менять нельзя. :(

эээ... нельзя перестроить индекс?

юзер-фриендли, ога :)

"Хочу просто UTF-8 и сортировку его же. Что писать в LC_CTYPE и LC_COLLATE? А есть универсальная вроде utf8_unicode_ci в MySQL?" а с этим как? Я чего-то совсем завис. Проставил везде C.UTF-8. Но я не уверен

так она по умолчанию UTF-8 уже не помню сколько лет. Для того, чтобы получить иную - да, надо ухищрятся (например, bacula требует строго ANSI)

эээ... нельзя перестроить индекс?

можно. Только надо пересоздать их все :)

так она по умолчанию UTF-8 уже не помню сколько лет. Для того, чтобы получить иную - да, надо ухищрятся (например, bacula требует строго ANSI)

зависит от выставленной системной локали. вроде как насколько помню

так она по умолчанию UTF-8 уже не помню сколько лет. Для того, чтобы получить иную - да, надо ухищрятся (например, bacula требует строго ANSI)

ок. как это можно увидеть. и что там за сортировка utf? она вообще достаточно неоднозначная. и как кстати может быть сортировка utf на базах в ascii, которые по умолчанию?

\l покажет и базы, и сортировки

Name | Owner | Encoding | Collate | Ctype | Access privileges ------------------+-----------------+-----------+-------------+-------------+----------------------- baculadb | postgres | SQL_ASCII | en_US.UTF-8 | en_US.UTF-8 |

ага. значи таки не utf8, а en_us

ощущаешь разницу?

postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges —---------+----------+-----------+---------+---------+---------------------— echostat | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =Tc/postgres + | | | | | postgres=CTc/postgres+ | | | | | echostat=CTc/postgres postgres | postgres | SQL_ASCII | C | C | template0 | postgres | SQL_ASCII | C | C | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | SQL_ASCII | C | C | =c/postgres + | | | | | postgres=CTc/postgres (4 rows)

echostat я сам создал с такими параметрами. а остальное было по дефолту. что-то оно далеко от UTF-8

на какой ос ?

в убунте по умолчанию будет UTF насколько я помню

Debian 8. а почему будет? какой UTF-8? en_US? А нафига он мне сдался? Или это не чистый en_US? А где почитать? А почему на другом дистрибутиве так будет? От чего это зависит? А точно будет?

в убунте по умолчанию будет UTF насколько я помню

и кстати только если ты системную локаль укажешь

и кстати только если ты системную локаль укажешь

я об этом и говорю.

#postgres #locale #encoding Отвечаю на свои вопросы. Раскопал 1. lc_ctype (для всяких нумераций и точек), lc_collate (для сортировки) Postgres умеет только те, что умеет glibc и установлены в системе. Т.е. он использует системные. С этим связаны и попытки стандартного клиента воспользоваться ими же. Поскольку исторически в Postgres зачем-то кувалдой вбита идеология системный пользователь === пользователю баз данных. Соответственно, если у вас в системе есть локаль, которая отсортирует и русский язык, и en_US и ss которая ß, то ок, нет - нет. Есть ли такое в Linux я хз. Похоже C.UTF-8, но я не уверен. Это такой вопрос для отдельного исследования и решение спорное. 2. encoding соответственно для хранения - то что прошито http://www.postgresql.org/docs/current/static/multibyte.html (и там таблицы соответствия). Походе UTF-8 он таки алиасит UTF8 и можно и так, и так писать. encoding используется для хранения и для конвертации между сервером и клиентом. Чтобы была конвертация, надо на клиенте сделать SET NAMES "блабла". Postgres достаточно однозначный - или конвертация есть, или её нет, голову сломать сложно. Имплементация кодировки и переконвертации свои, не системные (и таблицы свои, и вот это перечесление свое). 3. Кодировку/локаль если задали, то всё. Если какой-нибудь окорок запихал докером докер через докер чтобы докер SQL_ASCII или LC_COLLATE C - то это навсегда. И таких окороков 145%. Дамп, прибили базу, создали заново с новыми параметрами, залили обратно дамп. Это может и хорошо. Никогда не доверял это ALTER TABLE.

"стручок" initdb в этом кошмаре я пока не понял. пойму напишу

В postgres можно переписать какую-нибудь строчку в pg_hba не трогая этого pg_hba?

звучит как-то взаимоисключающе

типа поменять структуру памяти временно с новым конфигом?

не хочу трогать пакетный конфиг, хочу своим перебить

эм... а что будешь с postgresql.conf делать? и по факту, pg_hba это не пакетный конфиг. Он создается как раз при initdb и к пакета (rpm/deb) отношения не имеет

эм... а что будешь с postgresql.conf делать? и по факту, pg_hba это не пакетный конфиг. Он создается как раз при initdb и к пакета (rpm/deb) отношения не имеет

хм... а это интересно

Я что-то не могу никак найти место в конфиге, где префорк сделать. И как-то не гуглится

префорк чего?

Обработчиков запросов

эм... это что-то из мира httpd чтоль?

Ну как пул обработчиков сделать? Как-то эта тема даже не упоминается... Или я что-то пропустил