или exclude ...

#RuPostgres:
Сегодня, как обычно, в 18:30мск. В гостях будет Алексей Лесовский. Поговорим про: observability, диагностика, pgCenter.

YouTube-трансляция будет тут: https://youtu.be/yD3Ej4GVo-U

Zoom для активного участия: https://us02web.zoom.us/j/83259552989?pwd=bWQyZS9zcmZBWXkzakF4eCtvNzZpZz09 Meeting ID: 832 5955 2989 Password: 392784

Кидайте вопросы в комментах к youtube или в гуглодок: http://bit.ly/RuPostgresTuesday

до связи!

О, клёво!

EXCLUDE USING gist( ids WITH && ) из расширения intarray наверное вспоминается?
Оно только для интов и не в пределах массива работает, а между строками. То есть массив {200, 200} вставить даст. А вот потом в другую строку {100, 200} уже нет.
Можно функциональную проверку написать. Можно сделать триггер, который будет дублирующие значения убирать тихо при insert или update.
Но правильно будет - развернуть массив в таблицу

я там не уточнил, у меня на самом деле там varchar[]

Вообще там написано, я поэтому и подчеркнул "только int"

в общем, понятно - простым способом не получается...

и может еще такой вопрос пояснишь, насчет уровня изоляуции?
то есть вот у нас же READ COMMITED по умолчанию, и как там будет отпабатывать триггер на проверку уникальности?

Физически как это происходит?

Всем привет. Такая проблема - идем копирование в таблицу из csv (~2Gb) строк и в какой-то момент постгрес перестает различать строки и начинает все воспринимать как одну строку (как я полагаю) и падает с ошибкой переполнения буфера для копирования. Есть идеи какой символ это? эскейпятся переносы строки \n \r

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

>Если мы натыкаемся на конфликт в закомиченной и актуальной на момент старта транзакции строке, то сразу ловим violation.
>Если мы натыкаемся на конфликт с уже записанной другой транзакцией, но ещё не закомиченной строкой, то останавливаемся и ждём завершения той транзакции.
--> Если её закоммитили, то наша транзакция падает с violation.
--> Если откатили, то наша транзакция нормально продолжает работу.

Грубо говоря, оно работает так.
Ну и можно deadlock ещё поймать умеючи в теории.

А если триггер на проверку уникальности значений внутри array из одной  отдельной строки таблицы - всё вообще просто. У нас же есть и единственная верная текущая версия строки для транзакции и значения из query. Ну мы просто берём и прогоняем проверку по этим вот  уже имеющимся конкретным значениям.

Люди добрые, тупой вопрос. Поднял контейнер с БД пустой, сделал дамп и теперь не могу заресторится. пишет что -f -d нельзя вместе использовать

pg_restore -U dba -d cert_db -f cert_db.bak

что не так?

pg_restore -U dba -d cert_db < cert_db.bak
а если так попробовать

а дамп как делали?

там же при помощи pg_restore только архивные форматы восстанавливаются (Fd, Fc, Ft) а текстовый  при помощи psql

вот допустим у меня те же массивы варчаров, которые должны быть уникальны, на них есть гин индекс (без уникальности),
потом есть он-инсерт триггер, который ходит в этот индекс на предмет поиска дублей,
есть у него шансы не увидеть вставляемый дубль, если его в то же время закоммитила другая транзакция?

pg_restore: error: input file appears to be a text format dump. Please use psql.