Тут написано, что: PostgreSQL will detect this situation and abort one

of the transactions.
но если в данном примере
после второго апдейта в сессии А (из примера по ссылке) больше ничего не делать ни в какой транзакции, то они так и будут висеть.
не противоречие ли это?

Конечно, нет — deadlock-а то нет, а блокировки (по умолчанию) в любой СУБД могут удерживаться неограниченное время, я так слышал. ;) Если это не устраивает — настраивайте timeouts, что ж.

1.ну типа почему так блокировка прямо на statement-e? а не уже на попытке сделать коммит, где и можно было бы выдать ошибку (даже в режиме Serializable, кстати, такая блокировка) 2. почему тогда раздел доки называется deadlock?

1. Потому что это обычная эксклюзивная блокировка на UPDATE — так это везде работает (кроме СУБД, где используется OCC, но я их вживую не видел, например). 2. Потому что он про deadlocks, и полный пример по приведённой Вами ссылке именно его и демонстрирует (и такой же воспроизведётся практически в любой RDBMS)? Наверное, я не понял вопроса. ;(

2. я о том, что тут вы пишите что deadlockа нет, а сейчас, что пример про deadlock, значит он есть:) у меня диссонанс

Так там я пишу в ответ вот на это: > после второго апдейта в сессии А (из примера по ссылке) больше ничего не делать ни в какой транзакции, то они так и будут висеть. Т.е. при этом deadlock-а ещё нет. > а сейчас, что пример про deadlock Потому что полный пример действительно про deadlock. ;)

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

почему устроить не ожидание лока а просто падение при попытке коммита или прям на statement-e?

> в примере же такая история производит именно после того запроса, который я указал Нет, не происходит же? После него в "process B" можно делать почти что угодно (главное, не трогать locks, наложенные A). Т.е. он совсем не "висит" — иначе бы последний запрос в нём выполнить было бы невозможно. > а если все запросы оттуда запустить хоть и в указанном порядке, возникнет ошибка Какая ошибка? Если deadlock, то это нормально (RDBMS обязаны их обнаруживать и разрешать, в общем-то). > почему устроить не ожидание лока а просто падение при попытке коммита или прям на statement-e? Хмм... на каком именно, в каком процесcе (я запутался уже)? ;)

короче вы тестили этом пример?

Если честно — нет. Но он же тривиальный, с виду?

вот потестите:)

Ну и протестировал — это самый тривиальный deadlock ("смотрите в каждом учебнике по RDBMS"!): ERROR: deadlock detected DETAIL: Process 13564 waits for ShareLock on transaction 11820689; blocked by process 16952. Process 16952 waits for ShareLock on transaction 11820690; blocked by process 13564. HINT: See server log for query details. CONTEXT: while updating tuple (0,1) in relation "users" Что смущает-то?

как я описал тестили? видимо, нет

Видимо, да. Процесс A "висит" (блокирован процессом B), а вот процесс B работает, и так и должно быть — попробуйте это в любой обычной RDBMS, и увидите точно такое же поведение (с точностью до сообщений об ошибках). Я так и не понял, что Вас смущает... :(

то что процесс А висит. и полностью зависит от процесса В если процесс В будет стоять и ничего не делать, то и А тоже.

Да, и так работают вообще все СУБД, которые используют блокировки — прям открываете https://db-engines.com/en/ranking/relational+dbms и читаете по списку (пропуская те, которые non-ACID вообще (некоторые аналитические) и те, которые не многопользовательские), пока не дочитаете... до 131 позиции, если не вру. ;)

оптимистичные блокировки решили бы это?

Минуту. Вы про Optimistic Concurrency Control (хоть https://en.wikipedia.org/wiki/Optimistic_concurrency_control — так там просто транзакции откатывают по первому "чиху") или про https://www.ibm.com/docs/en/db2/11.5?topic=overview-optimistic-locking (совсем другая штука, хотя принцип похож... но я не совсем понимаю, как их тут использовать — если обновлять записи именно и только парой, то это всё равно транзакция и те же проблемы)?

ну:) почему по первому чиху? кто сделал коммит первый — тот выиграл. остальные в случае конфликтов откатываются. такого феномена как выше — когда А висит и ждёт чё там произойдёт в В — не было бы у вас другая инфа?

Ну так-то да, вроде (опять-таки, т.к. именно Relational DBMS, которые используют "чистый" OCC, в мире около одной, то я всё это помню очень смутно). ;) И то, что их так "много" — это жж неспроста (как говорят нам не только практики, но и теоретики — вон даже была книга кого-то из выдающихся, где он последовательно обосновывает примерно такое утверждение: "если DBMS с блокировками при высококонкурентной нагрузке проигрывает DBMS с OCC, это может значить только одно — у разработчиков первой кривые руки"). ;)

> т.к. именно Relational DBMS ну есть ещё NewSQL

Они-то чем не relational (большинство из них, по крайней мере)?

мне не могло быть известно, имеете вы их в виду или нет. вы там употребили слово «чистых» > в мире около одной вы о какой?

https://docs.mimer.com/MimerSqlManual/latest/Manuals/transactions_and_security/transactions_and_security.htm

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

Да, у меня другие данные — см. https://t.me/dba_ru/170096 Вас это не убеждает? Как то, что учёные (а не кто-нибудь) пишут с обоснованиями, что этот подход тупо хуже, так и то, что на практике таких СУБД где-то 1:200 (или даже более) остальных?

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

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

Так практически всегда можно найти примеры, на которых один подход для решения какой-то задачи лучше другого — на этом основан весь современный research в CS что тут такого? > то наверняка про общий перформанс двух подходов Да, именно так. > у вас другие данные? Нет. Т.е. Проблема только в том, что у любого подхода должны быть последовательно применяемые общие принципы, чтобы получилась ACID-СУБД, а не "каша". Тут нельзя "надёргать" из разных методов только то, что больше нравится. ;)