в нем есть гонка только в рид коммитед

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

Справедливости ради, мой совет тоже так себе. После считывания сиквенса, но до апсёрта кто-нибудь может вставить запись, которую апсёрт проапдейтит. 🤦‍♂️

вся логика должна быть в любом случае внутри транзакции нужного уровня, а проще всего ее делать в отдельной процедуре, иначе гонки 🤷‍♂️

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

и отлаживать такую процедуру проще, чем серию гибридной клиент-серверной логики

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

спасите помогите 🙂

Использую короткоживущие пользовательские сессии (облако), т.е. пользователи создаются с рандомными доступами на короткий срок, приводятся в нужный вид серией команд и отдаются приложению.

Пользователь создается так:

CREATE USER "{{name}}" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
GRANT project_rw TO "{{name}}";
ALTER ROLE "{{name}}" SET role project_rw;
ALTER ROLE "{{name}}" SET search_path TO django, public;

Сделал SET role project_rw чтобы объекты создаваемые пользователем (к примеру из автоматических миграций базы) принадлежали роли, а не текущему юзеру, иначе их потом никто не сможет поправить в другой миграции другим пользователем.  Но этого не происходит 🙁 созданные таблицы привязались к юзернейму. Что я делаю не так?

Юзер: \du
v-token-e2-DcAHSS2BOU79zKYO77QG-1589766669 | Password valid until 2020-05-19 01:51:14+00                | {project_rw}

Таблицы \dt django.*

django | merchants_productdata                        | table | mybaze_rw
django | pages_flexpage                               | table | mybaze_rw
django | search_terms_searchtermindexpage             | table | mybaze_rw
django | search_terms_searchtermpage                  | table | mybaze_rw
django | silk_profile                                 | table | v-token-e2-DcAHSS2BOU79zKYO77QG-1589766669
django | silk_profile_queries                         | table | v-token-e2-DcAHSS2BOU79zKYO77QG-1589766669
django | silk_request                                 | table | v-token-e2-DcAHSS2BOU79zKYO77QG-1589766669

и параметры были прописаны точно

https://take.ms/vrqXi

создал такого пользователя, пошел в базу, создал таблицу. все ок в овнерах не юзер, а его роль. почему же в миграции произошло иначе 😕

А почему до сих пор нету способа указать СУБД, сколько раз повторить всю транзакцию доп. параметром?

There is a possibility that a concurrent UPDATE or DELETE on the row being moved will get a serialization failure error. Suppose session 1 is performing an UPDATE on a partition key, and meanwhile a concurrent session 2 for which this row is visible performs an UPDATE or DELETE operation on this row. In such case, session 2's UPDATE or DELETE will detect the row movement and raise a serialization failure error (which always returns with an SQLSTATE code '40001'). Applications may wish to retry the transaction if this occurs. In the usual case where the table is not partitioned, or where there is no row movement, session 2 would have identified the newly updated row and carried out the UPDATE/DELETE on this new row version.

Спасибо, интересно.

Усомнила фраза
where there is no row movement, session 2 would have identified the newly updated row and carried out the UPDATE/DELETE on this new row version
кажется это отсноится только к RC. В RR и S будет ошибка.

> Даже с мгновенным deadlock detection можно в три сессии получить livelock.
Если одна сессия получает deadlock ошубку, то другая при этом выполняется. Т.е. если вы будете ретраить свои запросы, то в конце концов 3 сессии выполнят 3 запроса.

Люди, если у вас регулярно по три бекенда будут секунду висеть в дедлоке - вы далеко не уедете. Дедлоки надо предотвращать, а не "ретраить".

Сегодня конференция начинается https://learn.percona.com/percona-liveonline-24-hours-around-the-world-open-source-database-conference. Доклады вроде бы интересные обещают быть.

Ну, ретраить их тоже надо, поскольку окончательно предотвратить дэдлоки невозможно в принципе в многозадачной среде.

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

Чат, общетеоретический вопрос) А как вообще правильно:
- приложение отправляет запросы к таблицам, явно указывая схему
- приложение ничего не знает о схемах, всё рулится через search_path для роли под которой приложение работает.

Второй вариант авито упоминали на конференциях, когда выкатку новых фич порционно делали.
Ну а первый вариант... просто проще для дба?)

я привык указывать схемы

Да, действительно. С 3 сессиями можно придумать простой livelock, если очень не повезёт и будет откатываться не самая удачная транзакция.