14к коннектов.

и да я знаю что это косяк

интеерсно вообще бывает что бы все сработало ровно или надо привыкть переключать мастеров "руками"

а если перед Pgpool pgbouncer воткнуть ?

немогу. при вкорячивание все идет плохо

баг в приложении

печаль

сейчас мастер работает и работает норм

смущает только порядок перевода мастера

Если сделать pg_dump_all на 9.2 можно потом отресторить этот бекап на 9.4 ?

Скорее всего да.

9.3 => 9.5 работает хорошо

Мне нужно с 9.2 на 9.4 или 9.5

ну если не сработает, 9.2=>9.3 сначала можно

а дальше уж на любую

Хорошо попробую, спасибо.

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

pg_dump просто файл с sql запросами делает, нормально накатится на более свежую версию

А pg_upgrade не проще сделать?

к сожалению нет

Добрый день. Есть рекомендации по ввбору фс для постгрес?

Есть такие данные

http://www.slideshare.net/fuzzycz/postgresql-on-ext4-xfs-btrfs-and-zfs-54525451

Благодарю

Всем привет! Такой вопрос, имеем os x, на ней postgresql 9.5, база создавалась и с LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8’ и с ‘ru_RU.UTF-8’. Проблема в том, что при попытке сделать запрос вида ‘’’select * from custom_table order by custom_table.russian_field limit 100;’’’ выводятся данные без той сортировки, которая ожидалась.

Всем привет! Кто то может рассказать, это интересует меня на протяжении года, как в старых версиях делать upsert ? http://stackoverflow.com/questions/1109061/insert-on-duplicate-update-in-postgresql?answertab=votes#tab-top Вот тут есть решение, но позволяет обновлять по одной строчке, как можно сделать обновление пачки строчек? SELECT merge_db(1, 'david'),(3, 'dennis');

Всем привет! Такой вопрос, имеем os x, на ней postgresql 9.5, база создавалась и с LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8’ и с ‘ru_RU.UTF-8’. Проблема в том, что при попытке сделать запрос вида ‘’’select * from custom_table order by custom_table.russian_field limit 100;’’’ выводятся данные без той сортировки, которая ожидалась.

Покажи лучше вывод команды \l из psql для данного кластера (и данной БД соответсвенно)

из твоего объяснения я не очень понял как это "LC_CTYPE = 'en_US.UTF-8’ и с ‘ru_RU.UTF-8’."

Name | Owner | Encoding | Collate | Ctype | Access privileges ----------------------------+------------+----------+-------------+-------------+--------------------------- atomicworks | igorpavlov | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | atomicworks_test | igorpavlov | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | bin_development | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |

а вот с русским: bin1_development | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 |

Всем привет! Кто то может рассказать, это интересует меня на протяжении года, как в старых версиях делать upsert ? http://stackoverflow.com/questions/1109061/insert-on-duplicate-update-in-postgresql?answertab=votes#tab-top Вот тут есть решение, но позволяет обновлять по одной строчке, как можно сделать обновление пачки строчек? SELECT merge_db(1, 'david'),(3, 'dennis');

http://pastebin.com/NPJq3shj

Кажется, правильнее все же обновиться

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

можно конечно и обновиться

если позволяют условия эксплуатации текущие

Name | Owner | Encoding | Collate | Ctype | Access privileges ----------------------------+------------+----------+-------------+-------------+--------------------------- atomicworks | igorpavlov | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | atomicworks_test | igorpavlov | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | bin_development | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |

Так у тебя для всех collate=UTF8

он ничего про правила сортировки русского не знает как бы

так что поведение вроде как не противоречит настройкам

а сорри

не разгледел смещение

да, неудачно я отправил просто сюда)

тогда так

у тебя локаль называется ru_RU.UTF-8, а должна быть ru_RU.UTF8

разница в один "-", а какая разница...

http://pastebin.com/NPJq3shj

Спасибо огромное!

у тебя локаль называется ru_RU.UTF-8, а должна быть ru_RU.UTF8

интересно, сейчас попробую. Но такая локаль из коробки ставилась

из какой коробки?

Спасибо огромное!

учтите только, что если у вас параллельные писатели одно и то же будут инсертить, то при таком апсерте может возникнуть потенциальный конфликт по констрейнту уникальности. not exists не увидет незакоммиченные ряды, а insert дождется снятия блокировки и наткнется на конфликтующий ряд, и вывалит эксешпн более подробно можно почитать здесь https://www.postgresql.org/docs/9.4/static/index-unique-checks.html

просто я не трогал локаль, когда устанавливал это через brew

просто при инициализации кластера (команда initdb) была указана неправильная локаль и она теперь является дефолтной при создании базы

не увидит*

эм... сории, про brew ничего сказать не могу

оу, при initdb локаль не передавал)

слушай, а у тебя значит osx...

видимо, взялась системная

да, я же написал специально, что OS X

чет не разглядел

ну ты все равно проверь то, что я указал

ru_RU.UTF-8 не помогло

погоди

я же говорил ru_RU.UTF8

а, черт, минуту)

а ты новую БД создаешь проверяешь?

да

ERROR: S client not available

invalid locale name: "ru_RU.UTF8"

прикольно... да pg врде основывается на системых локалях

я в дампе правлю, делаю загрузку зампа

а UTF8 именно в OS X должна быть? просто винда\линух же UTF-8

на убунте под рукой encoding: UTF8, а collate UTF-8

и там работает?

да

на убунте под рукой encoding: UTF8, а collate UTF-8

ага, у меня тож также

вот мой вариант на linux (RHEL/CentOS) \l postgres List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges —--------+----------+----------+------------+------------+------------------- postgres | postgres | UTF8 | ru_RU.UTF8 | ru_RU.UTF8 | все работает

за сортировки ru_RU, а у тебя на ru_RU.UTF-8 - не работает сортировка?

у меня работает на ru_RU.UTF-8 сортировка на убунте. На маке с такой же локалью не работает)

Добрый день. Сегодня вдруг упала одна из баз данных с ошибкой вида «неверная страница в блоке ххх отношения /base/..." реиндексация, вакуум, падает на нем же. Стоит 9.3.4 1с. Пришлось откатываться на бэкап. Собственно из-за чего произошло это и как этого избежать в будущем? Можно ли восстановить уже пожилые данные до состояния консистентности?

select * from pg_collation where lower(collname) like '%ru%';

Добрый день. Сегодня вдруг упала одна из баз данных с ошибкой вида «неверная страница в блоке ххх отношения /base/..." реиндексация, вакуум, падает на нем же. Стоит 9.3.4 1с. Пришлось откатываться на бэкап. Собственно из-за чего произошло это и как этого избежать в будущем? Можно ли восстановить уже пожилые данные до состояния консистентности?

FS в норме?

collname | collnamespace | collowner | collencoding | collcollate | collctype -----------------+---------------+-----------+--------------+-----------------+----------------- ru_RU | 11 | 10 | 6 | ru_RU | ru_RU ru_RU.UTF-8 | 11 | 10 | 6 | ru_RU.UTF-8 | ru_RU.UTF-8

у меня сильно отличается...

я опустил)

collname | collnamespace | collowner | collencoding | collcollate | collctype -----------------+---------------+-----------+--------------+-----------------+----------------- ru_RU | 11 | 10 | 6 | ru_RU | ru_RU ru_RU | 11 | 10 | 20 | ru_RU.CP866 | ru_RU.CP866 ru_RU | 11 | 10 | 22 | ru_RU.KOI8-R | ru_RU.KOI8-R ru_RU | 11 | 10 | 23 | ru_RU.CP1251 | ru_RU.CP1251 ru_RU | 11 | 10 | 25 | ru_RU.ISO8859-5 | ru_RU.ISO8859-5 ru_RU.CP1251 | 11 | 10 | 23 | ru_RU.CP1251 | ru_RU.CP1251 ru_RU.CP866 | 11 | 10 | 20 | ru_RU.CP866 | ru_RU.CP866 ru_RU.ISO8859-5 | 11 | 10 | 25 | ru_RU.ISO8859-5 | ru_RU.ISO8859-5 ru_RU.KOI8-R | 11 | 10 | 22 | ru_RU.KOI8-R | ru_RU.KOI8-R ru_RU.UTF-8 | 11 | 10 | 6 | ru_RU.UTF-8 | ru_RU.UTF-8

хм.. прикольно как все от дистрибуции зависит

но все равно для сравнения мой вариант: select * from pg_collation where lower(collname) like '%ru%'; collname | collnamespace | collowner | collencoding | collcollate | collctype —------------------+---------------+-----------+--------------+--------------------+------------------— cv_RU | 11 | 10 | 6 | cv_RU | cv_RU cv_RU.utf8 | 11 | 10 | 6 | cv_RU.utf8 | cv_RU.utf8 ru_RU | 11 | 10 | 6 | ru_RU.utf8 | ru_RU.utf8 ru_RU | 11 | 10 | 22 | ru_RU.koi8r | ru_RU.koi8r ru_RU | 11 | 10 | 25 | ru_RU | ru_RU ru_RU.iso88595 | 11 | 10 | 25 | ru_RU.iso88595 | ru_RU.iso88595 ru_RU.koi8r | 11 | 10 | 22 | ru_RU.koi8r | ru_RU.koi8r ru_RU.utf8 | 11 | 10 | 6 | ru_RU.utf8 | ru_RU.utf8 ru_UA | 11 | 10 | 6 | ru_UA.utf8 | ru_UA.utf8 ru_UA | 11 | 10 | 34 | ru_UA | ru_UA ru_UA.koi8u | 11 | 10 | 34 | ru_UA.koi8u | ru_UA.koi8u ru_UA.utf8 | 11 | 10 | 6 | ru_UA.utf8 | ru_UA.utf8 russian | 11 | 10 | 25 | russian | russian tt_RU | 11 | 10 | 6 | tt_RU | tt_RU tt_RU.utf8 | 11 | 10 | 6 | tt_RU.utf8 | tt_RU.utf8 tt_RU.utf8@iqtelif | 11 | 10 | 6 | tt_RU.utf8@iqtelif | tt_RU.utf8@iqtelif tt_RU@iqtelif | 11 | 10 | 6 | tt_RU@iqtelif | tt_RU@iqtelif

Крутится на виртуалке, ext4.проблем замечено не было

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

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

хорошо, теперь подумаю, куда углубиться теперь xD

так, у тех, у кого на маке работает Collate «C» выставлен)

всю чудней и чудней

FS в норме?

Крутится на виртуалке, ext4.проблем замечено не было

< 2016-07-14 16:19:43.179 MSK >ПАНИКА: испорченный указатель элемента: смещение = 2240, размер = 48

вот это выходит при запуске vacuum

каждый раз

кластер новый