WHEN json :: JSON ->>bool = true THEN ... не работает?

WHEN json :: JSON ->>bool = true THEN ... не работает?

сорри. 1 сек

сорри понял затык.

к сожалению находу в голову ничего не приходит

понял, думаю дальше

можно join сделать, просто что два раза прийдется использовать json_array_elements. Сначала получить таблицу со всеми value, потом со всему bool, и джоинить их. Но может есть что то более изящное, менее затратное

Народ проснется, может чего посоветует

Ларчик просто открывался SELECT * FROM tbl t, json_array_elements(t.json_col->"json") AS elem WHERE elem->>'bool' = true;

Народ

А какое поведение будет если завести role with login, но без password

Залогиниться можно будет?

Можно

Если разрешишь в pg_hba.conf

Если разрешишь в pg_hba.conf

Аа

Точно

То есть, если в конфиге явно не заявлено разрешение, то держать роль без пароля безопасно?

думаю, да

Спасибо

То есть, если в конфиге явно не заявлено разрешение, то держать роль без пароля безопасно?

Я думал так все и делают. Например, создаешь роль readonly... А потом уже её назначаешь конкретным пользователям.

Доброе утро

сорян не туда написал)

Народ проснется, может чего посоветует

Тут недавно расширение рекламировали, которое позволяет писать запросы прямо на языке MongoDB: https://github.com/postgrespro/monq

Тут недавно расширение рекламировали, которое позволяет писать запросы прямо на языке MongoDB: https://github.com/postgrespro/monq

а причем тут это?

чел вопрос по json задавал

Не вижу противоречий )

ну ок. Мне казалось postgres sql чел спрашивал

то есть без расширений

Тут недавно расширение рекламировали, которое позволяет писать запросы прямо на языке MongoDB: https://github.com/postgrespro/monq

Та ну это жесть, что за каша получится)

Во время дампа укажите UTF8

Не помогает

при восстановлении получаю сообщения типа pg_restore: [archiver (db)] Error from TOC entry 13330; 2606 3734417 FK CONSTRAINT fk_t_workflownotification_t_users postgres pg_restore: [archiver (db)] could not execute query: ОШИБКА: отношение "vclib.t_users" РЅРµ существует Command was: ALTER TABLE ONLY t_workflownotification

Не помогает

В каком смысле? Дамп с ошибкой завершается? Получаемый файл не в той кодировке? Дамп не накатывается на новую базу?

дамп делается нормально

но не накатывается ан новую базу

на postgres под виндой

разворачивается все ок

а под linux никак

could not execute query: ОШИБКА: нет доступа к файлу "$libdir/citext": Нет такого файла или каталога

и т.п.

версии postgres какие?

А локаль виндовая для постгреса стоит на линухе?

и наоборот

Во-первых, не хватает модуля citext.

could not execute query: ОШИБКА: нет доступа к файлу "$libdir/citext": Нет такого файла или каталога

Yepp.... cp1251 ((( вронг локаль детектед )))

в линуксе нет локали винды

не стоит

https://postgrespro.ru/docs/postgrespro/9.6/locale

почитайте Алексей

Во-вторых, покажите locale в linux.

И всё-таки, дамп у вас получается в CP1251.

Привет, ребята. Хочу сделать синхронную потоковую репликацию master-slave. Обращаться к БД буду из Spring Boot проекта. Вопрос следующий: как проще и красивее сделать так, чтобы веб-приложение обращалось только к одному серверу, а все вопросы разруливания забрасывания запросов на чтение/запись выполнял кто-то другой?

Насколько я понимаю, так умеет pgpool, но может кто-то пробовал другие решения?

Привет, ребята. Хочу сделать синхронную потоковую репликацию master-slave. Обращаться к БД буду из Spring Boot проекта. Вопрос следующий: как проще и красивее сделать так, чтобы веб-приложение обращалось только к одному серверу, а все вопросы разруливания забрасывания запросов на чтение/запись выполнял кто-то другой?

1. Вы уверены, что хотите именно синхронную репликацию? Это боль. 2. pgpool умеет, а кто у вас ещё, кроме веб приложения есть?

1. Вы уверены, что хотите именно синхронную репликацию? Это боль. 2. pgpool умеет, а кто у вас ещё, кроме веб приложения есть?

1. Мне необходимо, чтобы отставание реплик от мастера было минимальным. А в чем заключается боль? 2. Кроме БД есть кеширование на уровне веб-сервера, кешируются редко изменяемые но часто запрашиваемые данные. Строго говоря, пока необходимости во всем этом нет. Единственный сервер вытаскивает по нагрузке. Но вскоре нагрузка может значительно вырасти и не хотелось бы делать масштабирование по ночам.

Боль в том, что синхронная реплика сильно аффектит мастер, особенно если есть хотя бы малейшие проблемы с сетью.

как можно сделать сковозной индекс на наследованные таблицы? :(

Боль в том, что синхронная реплика сильно аффектит мастер, особенно если есть хотя бы малейшие проблемы с сетью.

Насколько я понимаю, ее лучше избегать? Тогда я уточню свой вопрос: как лучше организовать масштабирование БД, если есть много важных данных (состояние счета, ставки и т.д.), которые часто меняются и требуется, чтобы пользователи всегда или почти всегда видели актуальные данные?

В 99% случаев достаточно асинхронной реплики. Отставание будет минимальным. Если для веба так, тем более. В мастер пишете - с реплики читаете, строите отчёты и т.д. Можно сделать несколько реплик и распределять нагрузку pgpool например. Если надо разгружать запись, то это уже сложнее. Как вариант - шардинг.

Шардинг предполагает, что каждый шард — это единый сервер? Или там тоже может быть связка со своей репликацией?

Например, вертикальный шардинг, где каждым шардом является свой мастер + два слэйва. Такое практикуют? :)

Шарды тоже могут иметь слейвы, конечно.

Окей, понятно. Спасибо вам большое!

короче, если вы вдруг через слоника создали роль, а на одном из участников репликации роль с таким именем уже существует, то вы получите следующее:

ERROR: S client not available

1. реплика на этой ноде встанет

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

короче, самое быстрое - переименовать роль

но иметь под рукой plain dump с этой базы, откуда можно оперативно забрать пермишены

Слоника?

Слоника?

что "слоника?"?

Слоника?

http://slony.info/documentation/slonik.html ?

да

лол

а почему она так называется?

русские писали?

:)

русские писали?

ну да

поздравляю тебя с открытие слона ))

хорошая штука

позволяет реплицировать БД частично между любыми версиями постгреса

каскадно

есть хаятушник чтобы быренько сделать постгерсс на 50к коннектов с сек и столько же записей?

хорошая штука

Умей оно реплицировать несколько баз, цены бы ей не было. А так одна база - один управляющий демон. А если баз - за сотню?

Умей оно реплицировать несколько баз, цены бы ей не было. А так одна база - один управляющий демон. А если баз - за сотню?

Не понял?

Один слоник может только одну базу. А я встречал сервера, где баз было за сотню.

Один слоник может только одну базу. А я встречал сервера, где баз было за сотню.

Гм

У меня в црм одни демон три базы тащит

Один слоник может только одну базу. А я встречал сервера, где баз было за сотню.

больше слоников - больше баз?

Один слоник может только одну базу. А я встречал сервера, где баз было за сотню.

Ты, наверное, не в теме что там коефиги надо разные

Под каждую бд свой конфиг

Но демон один

В /etc/slony создаёшь директорию под каждый конфиг

У меня в црм одни демон три базы тащит

Точно один демон? А то больше похоже на то, что один старт скрипт запускает нужное количество демонов по одному на каждый конфиг. Со стороны кажется, что один, а реально - столько, сколько конфигов. Ибо, помимо всего прочего слону (демону) нужно коннектор к базе указывать.