database-deadlocks

问题 This question can be considered as a follow-up on my comment on Can two concurrent but identical DELETE statements cause a deadlock?. I am wondering if the rows are locked in ascending my_status order in the following statement: SELECT 1 FROM my_table ORDER BY my_status FOR UPDATE; There is an interesting remark on https://www.postgresql.org/docs/9.5/static/sql-select.html which says: It is possible for a SELECT command running at the READ COMMITTED transaction isolation level and using ORDER

问题 This question can be considered as a follow-up on my comment on Can two concurrent but identical DELETE statements cause a deadlock?. I am wondering if the rows are locked in ascending my_status order in the following statement: SELECT 1 FROM my_table ORDER BY my_status FOR UPDATE; There is an interesting remark on https://www.postgresql.org/docs/9.5/static/sql-select.html which says: It is possible for a SELECT command running at the READ COMMITTED transaction isolation level and using ORDER

问题 This question can be considered as a follow-up on my comment on Can two concurrent but identical DELETE statements cause a deadlock?. I am wondering if the rows are locked in ascending my_status order in the following statement: SELECT 1 FROM my_table ORDER BY my_status FOR UPDATE; There is an interesting remark on https://www.postgresql.org/docs/9.5/static/sql-select.html which says: It is possible for a SELECT command running at the READ COMMITTED transaction isolation level and using ORDER

问题 I need to do a Postgres update on a collection of records & I'm trying to prevent a deadlock which appeared in the stress tests. The typical resolution to this is to update records in a certain order, by ID for example - but it seems that Postgres doesn't allow ORDER BY for UPDATE. Assuming I need to do an update, for example: UPDATE BALANCES WHERE ID IN (SELECT ID FROM some_function() ORDER BY ID); results in deadlocks when you run 200 queries concurrently. What to do? I'm looking for a

问题 i have a stored procedure that performs a join of TableB to TableA : SELECT <--- Nested <--- TableA Loop <-- | ---TableB At the same time, in a transaction, rows are inserted into TableA , and then into TableB . This situation is occasionally causing deadlocks, as the stored procedure select grabs rows from TableB , while the insert adds rows to TableA , and then each wants the other to let go of the other table: INSERT SELECT ========= ======== Lock A Lock B Insert A Select B Want B Want A .

问题 I would like to understand better a mechanism of locking in postgres. Let's say that tree can have apples (via foreign key on apple table). It seems that when selecting a tree for update lock is obtained on an apple. However, the operation is not blocked even if someone else already holds a lock on this apple. Why is it so? p.s. Please don't suggest to remove "select for update". Scenario Transaction 1 Transaction 2 BEGIN . update apple; . . BEGIN . select tree for update; . update apple; . -

问题 I have searched for quite some time now and can't found a solution to my problem. We are using SQLAlchemy in conjunction with MySQL for our project and we encounter several time the dreaded error: 1213, 'Deadlock found when trying to get lock; try restarting transaction'. We would like to try to restart the transaction at most three times in this case. I have started to write a decorator that does this but i don't know how to save the session state before the fail and retry the same

问题 I use PostgreSQL 9.2, and I do not use explicit locking anywhere, neither LOCK statement nor SELECT ... FOR UPDATE . However, recently I got ERROR: 40P01: deadlock detected . The query where deadlock was detected is wrapped in transaction block though. Anyway, how comes it? 回答1: You don't need any explicit LOCK to go into a deadlock. Here's a very simple demo from scratch with only INSERTs: create table a(i int primary key); create table b(i int primary key); Session #1 does: begin; insert

问题 We have a single table which does not have references to any other tables. ┬────────────┬─────────────┬───────────────┬───────────────╮ │id_A(bigint)│id_B(bigint) │val_1(varchar) │val_2(varchar) │ ╪════════════╪═════════════╪═══════════════╪═══════════════╡ The primary key of the table is a composite of id_A and id_B. Reads and writes of this table are highly concurrent and the table has millions of rows. We have several stored procedures which do mass updates and deletes. Those stored

问题 I have a MySQL table with about 5,000,000 rows that are being constantly updated in small ways by parallel Perl processes connecting via DBI. The table has about 10 columns and several indexes. One fairly common operation gives rise to the following error sometimes: DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction at Db.pm line 276. The SQL statement that triggers the error is something like this: UPDATE file_table SET a_lock = 'process-1234'