PostgreSQL是否存在低优先级查询？如何让维护任务给业务请求让路

方案1：会话级锁超时配置（匹配你设想的参数实现） #

你需要的SESSION级锁等待容忍时间参数原生存在，配置后可直接实现优先级效果：
在维护脚本的最开头执行以下参数设置：

-- 设置当前会话所有语句等待锁的最长时间，超过则当前语句主动抛出错误中断，不会影响已持有锁的业务读请求
SET lock_timeout = '100ms';
-- 可选额外配置单条语句最长执行时间，避免慢语句长期占用资源
SET statement_timeout = '30s';

你可以根据业务容忍度调整lock_timeout的阈值，锁超时触发后仅中断维护脚本当前执行的语句，被阻塞的读请求不会受任何影响，完全符合你需要的优先级规则。

方案2：类AUTOVACUUM主动中断机制 #

如果需要更贴近AUTOVACUUM的「发现阻塞就主动让步」逻辑，可以在维护脚本中增加阻塞检测逻辑，每执行一批操作前先做检查：

1. 先通过以下SQL判断当前维护会话是否已经阻塞了其他业务请求：

SELECT EXISTS (
    SELECT 1 FROM pg_locks blocked_lock
    JOIN pg_stat_activity blocked_activity 
        ON blocked_lock.pid = blocked_activity.pid
    WHERE blocked_lock.granted = false
    -- 排除维护脚本自身的会话
    AND blocked_activity.application_name != 'your_maintenance_script_name'
    -- 匹配当前维护会话持有的锁
    AND EXISTS (
        SELECT 1 FROM pg_locks current_lock
        WHERE current_lock.pid = pg_backend_pid()
        AND current_lock.locktype = blocked_lock.locktype
        AND current_lock.relation = blocked_lock.relation
        AND current_lock.granted = true
    )
);

2. 若上述查询返回true，说明当前维护脚本已经阻塞了其他请求，直接中断当前批次操作，休眠1-2秒后再重试后续操作。

优化建议 #

• 把大的INSERT、UPDATE操作拆分为单次操作100-1000行的小批次，每批次执行完成后立即提交，大幅降低锁的持有时长，从源头减少阻塞概率
• 维护脚本尽量调度在业务低峰期运行，进一步降低和读请求的冲突概率
• 额外配置SET idle_in_transaction_session_timeout = '1min';，避免维护脚本出现异常挂起的事务长期持有锁

内容的提问来源于stack exchange，提问作者Alexi Theodore