Problem
In #1023 atepg.AcquireLock currently runs DELETE FROM leases WHERE expires_at <= clock_timestamp() before every lease acquisition. The expires_at index keeps this bounded, but it still adds an extra database write and round trip to every lock acquisition, including when there are no expired leases.
The acquisition query already reclaims an expired lease for the requested key through INSERT ... ON CONFLICT ... DO UPDATE ... WHERE leases.expires_at <= clock_timestamp(), so global cleanup is not required for lock correctness. It only prevents expired rows for inactive keys from accumulating.
Proposed follow-up
Move global expired-lease cleanup off the acquisition path, for example to a periodic background task with a bounded interval and/or batch size. In a multi-replica deployment, ensure cleanup work is not needlessly duplicated or that concurrent cleaners remain cheap and safe.
Problem
In #1023
atepg.AcquireLockcurrently runsDELETE FROM leases WHERE expires_at <= clock_timestamp()before every lease acquisition. Theexpires_atindex keeps this bounded, but it still adds an extra database write and round trip to every lock acquisition, including when there are no expired leases.The acquisition query already reclaims an expired lease for the requested key through
INSERT ... ON CONFLICT ... DO UPDATE ... WHERE leases.expires_at <= clock_timestamp(), so global cleanup is not required for lock correctness. It only prevents expired rows for inactive keys from accumulating.Proposed follow-up
Move global expired-lease cleanup off the acquisition path, for example to a periodic background task with a bounded interval and/or batch size. In a multi-replica deployment, ensure cleanup work is not needlessly duplicated or that concurrent cleaners remain cheap and safe.