Hello, We've put a lot of effort (as I know many others have) into ensuring any DDL we run in production doesn't block (or, at least, doesn't block for more than a very short amount of time). That includes the obvious: e.g., don't do operations that require rewriting or scanning a large table under an exclusive lock. Another key piece is relying on a small lock_timeout value to ensure that when we do take out exclusive locks we don't cause a large amount of queuing by having the AccessExclusiveLock acquisition itself queued behind a long-running query.
In our normal use setting lock_timeout happens inside libraries so we don't have to think about it, but occasionally we have a use case that isn't using those libraries, and that creates a foot-gun for us. The obvious question would be: why not just set lock_timeout globally? In practice that's not necessarily reasonable because it applies equally to all lock types. A couple of examples: - Table level: SELECTs or UPDATEs queue on a short-lived exclusive lock: we don't want to timeout lock acquisition on these at all. - Row level: we want to allow updates to the same rows (e.g., different columns, non conflicting) to execute sequentially without a lock timeout. But we don't want to allow reads or writes to queue for more than a few seconds behind AccessExclusiveLock or even ShareLock. I'm wondering if adding the ability to configure lock_timeout at a more granular level is something that would be a reasonable solution to this problem, or if folks think there's a better way to solve the problem. Regards, James Coleman
