mirror of https://github.com/zulip/zulip.git
28173cafc8
Previously, an active production Zulip server would experience a class of deadlocks caused by two or more concurrent bulk update operations on the UserMessage table. This is because UPDATE ... SET ... WHERE statements that execute in parallel take row-level UPDATE locks as they get results; since the query plans may result in getting rows in different orders between two queries, this can result in deadlocks. Some databases allow ORDER BY on their UPDATE ... WHERE statements; PostgreSQL does not. In PostgreSQL, the answer is to do a sub-select with an ORDER BY ... FOR UPDATE to ensure consistent ordering on row locks. We do this all code paths using bitand or bitor as part of bulk editing message flags, which should ensure that these concurrent operations obtain row level locks on the table in the same order. Fixes #19054. |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| alert_words.py | ||
| bots.py | ||
| create_realm.py | ||
| create_user.py | ||
| custom_profile_fields.py | ||
| default_streams.py | ||
| hotspots.py | ||
| invites.py | ||
| message_delete.py | ||
| message_edit.py | ||
| message_flags.py | ||
| message_send.py | ||
| muted_users.py | ||
| presence.py | ||
| reactions.py | ||
| realm_domains.py | ||
| realm_emoji.py | ||
| realm_export.py | ||
| realm_icon.py | ||
| realm_linkifiers.py | ||
| realm_logo.py | ||
| realm_playgrounds.py | ||
| realm_settings.py | ||
| streams.py | ||
| submessage.py | ||
| typing.py | ||
| uploads.py | ||
| user_activity.py | ||
| user_groups.py | ||
| user_settings.py | ||
| user_topics.py | ||
| users.py | ||
| video_calls.py | ||