You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Fix the tag updates atomicity and deadlocks
* Replace `Map.drop()` with `Map.take()` as per Liam's feedback in DM
* Fix error handling since there will be a tuple of more than 2 items returned as per docs
* Replace `+1` with `1` for update_images_counts
* Rename `update_images_counts` to `update_image_counts` and replace `case` with a function-level match
* Replace the capture operator with an explicit `fn tag_name ->`
* Fix remove repo nil match autocompleted by Github Copilot (bruh)
# There is a really delicate nuance that must be known to avoid deadlocks in
29
+
# vectorized mutation queries such as `INSERT ON CONFLICT UPDATE`, `UPDATE`,
30
+
# `DELETE`, `SELECT FOR [NO KEY] UPDATE` that touch multiple records. Note that
31
+
# `INSERT ON CONFLICT DO NOTHING` doesn't lock the conflicting records, so this
32
+
# nuance doesn't apply in that case (https://dba.stackexchange.com/questions/322912/will-insert-on-conflict-do-nothing-lock-the-row-in-case-of-conflict)
33
+
#
34
+
# If a vectorized mutation is run without a consistent locking order of the records,
35
+
# it can end up with a deadlock where one transaction locks a set of records
36
+
# that overlap with the other transaction while the other transaction locks
37
+
# the other set that overlaps with the first transaction. Thus, both transactions
38
+
# wait for each other to release the locks on records they locked resulting in
39
+
# a deadlock.
40
+
#
41
+
# For raw `UPDATE/DELETE ... WHERE ... IN (...)` queries, the items inside `IN (...)`
42
+
# don't influence the order of locking. These queries also don't have an `ORDER BY`
43
+
# clause. Thus, this function returns a `SELECT [lock_type]` query that establishes a
44
+
# consistent order of records by primary keys that must be used with all vectorized
45
+
# mutation queries to avoid deadlocks. This query can be used as a subquery in
46
+
# the `WHERE` clause for the vectorized mutation.
47
+
#
48
+
# If no locking order is set, the deadlock can appear randomly and its probability
49
+
# increases with the amount of items in the vectorized mutation query and with
50
+
# the number of overlapping records in concurrent transactions.
51
+
#
52
+
# This phenomena was discovered when @MareStare was trying to parallelize
53
+
# the image creation process for seeding the images during development, where
54
+
# tons of image uploads are issued in parallel with many overlapping tags
0 commit comments