-
Notifications
You must be signed in to change notification settings - Fork 4.1k
sql/kv: implement lock_timeout session variable #67513
Copy link
Copy link
Closed
Labels
A-kv-transactionsRelating to MVCC and the transactional model.Relating to MVCC and the transactional model.A-sql-pgcompatSemantic compatibility with PostgreSQLSemantic compatibility with PostgreSQLC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)T-kvKV TeamKV TeamT-sql-foundationsSQL Foundations Team (formerly SQL Schema + SQL Sessions)SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Metadata
Metadata
Assignees
Labels
A-kv-transactionsRelating to MVCC and the transactional model.Relating to MVCC and the transactional model.A-sql-pgcompatSemantic compatibility with PostgreSQLSemantic compatibility with PostgreSQLC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)T-kvKV TeamKV TeamT-sql-foundationsSQL Foundations Team (formerly SQL Schema + SQL Sessions)SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Postgres has a configuration to limit the amount of time a given statement waits to acquire an individual lock: https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-LOCK-TIMEOUT
We currently accept this session variable, but ignore it.
This would provide a more targeted solution for the same "lock bloat" problem detailed in #66017. The implementation of this would be fairly straightforward. We would introduce a new
lock_timeoutfield onroachpb.Headerand plumb this down to thelockTableWaiter. It would be similar to #52388.