Вручную конечно же заходит с паролем из pg_pass

сейчас сначала поругают про "постгре", а потом скажут про права на файл и pg_hba :)

Простите, постгрес ;d

на pg_pass владелец я, '600'
конекчусь локально

  psql -h $SRC_HOST -p $SRC_PORT -d $SRC_DB -U $SRC_USER -w --tuples-only --no-align 

psql: FATAL:  password authentication failed for user "postgres"
password retrieved from file "/home/maksim.mahalov/.pgpass"

а без -w ?

Привет. Подскажите пожалуйста, есть ли какие-то надстройки над pg_repack, которые умееют перезапускать с того же места, где произошла ошибка?

И еще один вопрос - на таблице есть uniq constraint по колонке name, но как-то получилось, что есть 2 строки с одинковым значением в колонке. Если искать по значению колонки, то найдется только одна строка, но по конкретным Id находится обе строки. Какие здесь могут быть варианты? какие-то особенности collation?

В смысле "раз write skew, значит чушь"?  Write skew это как раз когда у нас несколько транзакций берут один набор данных, делают на своей копии disjoint updates и коммитят это, в итоге ломая конечное значение в слабопредсказуемую сторону.  Мы тут про это и говорим вроде бы.
Ну и таки postgres же не тупо так делает, а манипулирует с блокировками обновляемых строк и перепроверками. Да, есть некоторые corner case,  типа как в документации, но вообще оно вполне себе такие проблемы обрабатывает, а в этой конкретно статье даже не сильно наврано. Конкретно constraint проломить, о чём вопрос и был, точно не выйдет.

> В смысле "раз write skew, значит чушь"?

Нет. То, что на RC не возникает write skew — чушь.

> Write skew это как раз когда

Да, это, на первый взгляд, правильное описание аномалии. И на RC она, разумеется, возможна.

> Ну и таки postgres же не тупо так делает, а манипулирует с блокировками обновляемых строк и перепроверками.

И для "защиты" от write skew всё это бесполезно — write sets при write skew не пересекаются.

> Конкретно constraint проломить, о чём вопрос и был, точно не выйдет.

Какой конкретно constraint (где его код)? Но если это что-то подобное уникальности — почти наверняка выйдет, причём, скорее всего, запросто. ;)

#вакансия #wildberries #dataengineer
Позиция:  Middle Data Engineer
Локация: Москва
Условия: fulltime/ удалёнка, 120-150 т.р. на руки

Чем предстоит заниматься:
- Администрированием кластеров: Greenplum, Postgres
- Обеспечением отказоустойчивости
- Резервным копированием и восстановлением
- Оптимизацией SQL запросов и производительности БД

Что для нас важно:
- Уверенный опыт работы с Postgres
- Опыт администрирования PostgreSQL (от 1 года)
- Опыт оптимзации SQL кода (от 2х лет)
- Опыт работы с высоконагруженными БД 24х7
- Навыки bash и python
- Понимание принципов кластеризации, высокой доступности и отказоустойчивости
- Умение и желание решать технические проблемы
- Способность к системному мышлению и перспективному планированию
- Желание совершенствовать свои навыки и способности
- Понимание важности документирования проделанной работы

Что кроме зарплаты:
- Бесплатное безлимитное питание в офисе (контейнеры, фрукты, кофе машины, автоматы)
- Большие скидки на продукцию компании + кэшбек ~20% - 30%
- Возможность отложенной покупки
- Поездки команд в Европу и по России - "отдохнуть и поработать" (последние локации были Кипр и Сочи)
- Спортивные мероприятия (футбол, волейбол, йога)
- Скидки на английский (онлайн и с преподавателем в офисе) и в фитнес-клубы рядом с офисом
- Широкий пакет плюшек для детей сотрудников: подарки на праздники, детские корпоративы в офисе, курсы для детей по ИТи т.д.)
- Скидка на паркинг 30% (в районе 5300 получается со скидкой)
- 3 дня в неделю удалённо и 2 дня в офисе
- Железо на выбор (Mac, iMaс, PC)

Контакты:
Телеграм - @avelestat почта -  kim.lestat@wildberries.ru

И так. по вчерашнему вопросу по поводу триггера. сделали две разные базы, в одной включили триггер, в другой - отключили. добавляли 10к записей. разница скорости получилась примерно в 2 раза, что объяснимо и допустимо.
так что вопрос снимается.
советы по схеме посмотрю и схему поправлю
всем огромное спасибо!!!!

Мы сделали update в первой транзакции.  Вторая зависла в блокировке на update этого же места. Закоммитили первую,  вторая разблокировалась, перечитала измененные данные, сделала update уже этих значений, причём уникальность проверяется вот в процессе этого апдейта . Я тут варианта проломить уникальность даже в масштабах unique key, а не просто  содержимого массива в отдельной строке в упор не вижу, особенно при дефолтном initially immediate у uk.

В общем спорить по этому самому интересному пункту не стану, нужно сесть и порисовать, вдруг я что-то пропустил.

Вы бы всё-таки EXPLAIN (ANALYZE) проверили, как я показывал — там же более-менее точно выдаётся, сколько занимает именно выполнение триггеров (особенно наглядно будет, если это массовая вставка, т.е. COPY и multi-insert).

проблема в том, что EXPLAIN (ANALYZE) выдается только для одного запроса. блок do не обрабатывается целиком, и по одному запросу мало что скажешь на реальных данных

Рассуждения такого рода обычно бесполезны, правда (потому что почти всегда почему-то выясняется, что "я не такой код имел в  виду"). ;)
Т.е. разбирать стоит только конкретный код.

Ну изначально вообще вопрос стоял о проверке уникальности элементов в массиве в рамках отдельно взятой ячейки из отдельно взятой строки. То есть по сути check с функцией.
Да, так делать плохо и нельзя, я написал. А вопрос с адекватностью такой проверки в ситуации конкуррентных транзакций остался. Ибо вообще интересный.

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

> Ну изначально вообще вопрос стоял о проверке уникальности элементов в массиве в рамках отдельно взятой ячейки из отдельно взятой строки.

Разве? Я прочитал, как "во всей таблице"...

> Да, так делать плохо и нельзя, я написал.

Если в такой постановке — почему нет? CHECK должно быть достаточно, на первый взгляд.

> А вопрос с адекватностью такой проверки в ситуации конкуррентных транзакций остался.

Конкретный код нужен.

> Ибо вообще интересный.

Ну фу (понапишут всякой дряни на RC, а потом удивляются, что у них в данных мусор).
Т.е. мне, например, не интересно — SERIALIZABLE и нечего тут думать. ;)

> SERIALIZABLE
Скучно, оно просто работает)