pg_get_indexdef()

+100500

Спасибо

Именно то, что надо

если именно всех - думаю проще будет запрос select * from pg_indexes ;

Привет всем. Посоветуйте как превратить вывод селекта из одного стобца в строку через запятую?

string_agg вроде

select array_to_string(array_agg(g), ',') from generate_series(1,10) g;

Почитайте тут, что-то может подойти http://pgday.ru/files/pgmaster14/max.boguk.query.optimization.pdf

Проверил щас, да, string_agg(col, ',') будет работать как надо.

select array_to_string(array_agg(g), ',') from generate_series(1,10) g;

Over-engineering :)

Проверил щас, да, string_agg(col, ',') будет работать как надо.

да спасибо

только ещё бы от заголовка избавиться

Какого еще заголовка?

типа такого string_agg ------------ blabla (1 row)

Подозреваю, что тебе надо просто добавить ... AS myText

Ну да.

Подозреваю, что тебе надо просто добавить ... AS myText

нет

Ну ведь да

Покажи запрос

мне нужно читую стороку

select string_agg(table_name,', ') from information_schema.columns where table_schema='contingent' and table_name like '%binding';

Psql ?

Так это у тебя в одиночном селекте оно показывает имя, так всегда.

-t

Это нормально. По факту выбирается только значение

ты имеешь ввиду форматирование?

-t

Да )))

-t

да оно, спасибо

А что оно делает?

Я что то не понял значит видимо :)

Форматирует вывод psql (-t - без всего ))

Over-engineering :)

мне тоже казалось, что есть что-то проще, но вспомнил только это :))

Ох ребята-ребята, нарвался на грабли с pg_repack. Поставили на выходные табличку репакаться, все успешно репакнулось, но вот беда, прод слег, с утра разбирались, оказалось, что не все гладко он делает, там набилось 300+ UPDATE waiting на эту таблицу после репака и висело 6+ часов пока админы не сели выяснять что не так. Так что мониторьте кол-во вейтингов если юзаете pg_repack.

Если что, постгри 9.4

Ничему верить нельзя в мире постгри.

Ничему верить нельзя в мире постгри.

"в мире постгри" - лишнее.

В мире мускуля как раз все намного прозрачнее.

В мире мыскля своих забав хватает более чем.

Но еще раз, там все предсказуемо и ожидаемо. Включая проблемы консистентности и проблемы репликации. Все давно изучено и задокументировано.

а pg_repack в коре? ох уж этот обманчивый мир постгри

Станислав, а поведение сторонних продуктов в мире мыскля так же предсказуемо и ожидаемо, или всё-таки есть подводные камни. Я вот думаю, что подводные камни таки есть.

Я думаю, что все согласны, что VACUUM FULL с продакшеном, мягко говоря, плохо совместим.

А полное перестроение объектов в постгре без их эксклюзивной блокировки - это вот такой вот интересный миф. На который народ почему-то ведётся.

Я вот, например, не могу понять логики, которая позволяет заявлять о перестроении таблиц и индексов без их полной блокировки, на данных, которые в работе: вставляются, удаляются, изменяются, ну и вот это всё

Бизнесу эти проблемы не интересны. Бизнесу нужна непрерывность.

http://momjian.us/main/writings/pgsql/features.pdf

Один программист начал делать табличку CREATE TABLE t2 AS SELECT * FROM t1; Все шло неплохо в течение 50 часов, пока необходимость в табличке не отпала и программист не нажал Ctrl+C. Отмена прошла быстро, а вот табличка - осталась. Разбирательсва показали, что виноват был автовакуум, которому по-хорошему нужно пропатчить мозги и запретить лезть к удаляемым табличкам.

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

а select into не получалось?

а какая разница?

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

никакого постгри не существует, есть постгрес

а select into не получалось?

»This command is functionally similar to SELECT INTO, but it is preferred since it is less likely to be confused with other uses of the SELECT INTO syntax. Furthermore, CREATE TABLE AS offers a superset of the functionality offered by SELECT INTO.

ясно

ERROR: timestamp out of range - кто-нибудь сталкивался с подобной ошибкой? Никаких предпосылок не было. Произошло на 9.4.6.

также сценарий восстановления: создание нового кластера и восстановление из резервной копии? или есть другие варианты?

в окрестностях mysql_fdw что-то такое было

Все, нашел. my bad, приходил oom. БД неважная, никто ее не настраивал. Восстанавлю из бэкапа. заодно и на 9.5 обновлю

извините за оффтоп: о скидках на highload никто ничего не слышал? постгрес про среди партнёров числится.

никакого постгри не существует, есть постгрес

?

Все, нашел. my bad, приходил oom. БД неважная, никто ее не настраивал. Восстанавлю из бэкапа. заодно и на 9.5 обновлю

А как OOM оказался связан с ошибкой?

Доброго дня! Подскажите, пожалуйста, как себя ведут триггеры на READ ONLY реплике? У меня есть DML-триггеры, которые не хотелось бы, чтобы работали на реплике - они вызывают внешние функции отправки данных.

в функциях проверяйте pg_is_in_recovery()

ERROR: S client not available

@kshvakov Я правильно понимаю, что он возвращает TRUE на реплике?

@kshvakov Я правильно понимаю, что он возвращает TRUE на реплике?

Да

Бессмысленное действие. Они и так не работают. Т.к. на реплике не выполняются DML. Репликация физическая, а не логическая. Мы же про стриминг говорим

Т.е. так и так ни один BEFORE/AFTER INSERT/UPDATE/DELETE триггер не сработает?

Триггер срабатывает при выполнении DML. При накате по стримингу DML не выполняется. Что должно быть причиной вызова триггера?

у вас ПОТОКОВАЯ репликация. Реплицируется физика а не команды

Согласен, просто это будет первый раз, когда буду настраивать репликацию. Спасибо всем за разъяснения!

Если у вас триггеры дергают внешние функции, то тут вопрос к архитектуре приложения т.к. нарушена транзакционность. По идее, триггеры должны писать в очередь, типа RabbitMQ например, а функции выгрузки данных должны из нее выгребать. Тогда даже если кто-то на реплике дернет руками DML (который естественно не отработает и откатится), но при этом сработает before trigger - ничего гарантированно не сломается. Можно конечно костыль в виде pg_is_in_recovery(). Но лучше решать такие вещи на уровне архитектуры, а не кода.

Ну это я спросил тоже из соображения паранои... На самом деле всё, что отправляется наружу через триггеры основано на уникальных ключах и ничего плохого не случится... А вообще мне очень не хватает oracle change notification... с ним мне было бы куда проще

Мне и AWR и скедулера и Advanced Queue не хватает... И ещё всяко разно по мелочи. Но кто ж нас спрашивает...

scheduler - таки да... о нём тож забыл... но его реализация вроде как есть, хотя и сомнительна

Джобы из pgAdmin - это боль. Я лучше буду из крона. Так я буду хоть в чём-то уверен.

Ну да... тоже так думаю

А как OOM оказался связан с ошибкой?

Когда у тебя кто-то посылает SIGKILL процессам БД может произойти что угодно. Например повреждение данных. Или потеря.

Когда у тебя кто-то посылает SIGKILL процессам БД может произойти что угодно. Например повреждение данных. Или потеря.

Тут опять кто-то fsync в off выкрутил?

Тут опять кто-то fsync в off выкрутил?

нет. Но разве ошибок в ядре мало? Вот в 9.4.7, например Avoid unlikely data-loss scenarios due to renaming files without adequate fsync() calls before and after (Michael Paquier, Tomas Vondra, Andres Freund)

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

Коллеги из PGPro подскажите https://github.com/postgrespro/postgrespro эта сборка для комерческого использования бесплатна ?

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

Ты не прав. Есть куча софта, который распространяется в открытом виде, но использование в коммерческих целях запрещено.

GPL?

Вот пример http://www.highcharts.com/

В репке же лежит файл, который назвывается COPYRIGHT, вы его читать пробовали?

В репке же лежит файл, который назвывается COPYRIGHT, вы его читать пробовали?

Никогда. Привычка от винды осталась.

https://postgrespro.ru/products/postgrespro

Юрий , спасибо!

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

array[]::varchar[] ?

аргемент соответственно varchar[] или char[] что там вам надо

string_to_array функция