max_locks_per_transaction
| 버전 | 기본값 | context | 타입 |
|---|---|---|---|
| 14 | — | postmaster (재시작) | integer |
| 15 | — | postmaster (재시작) | integer |
| 16 | — | postmaster (재시작) | integer |
| 17 | — | postmaster (재시작) | integer |
| 18 | — | postmaster (재시작) | integer |
| 19 | — | postmaster (재시작) | integer |
공유 lock 테이블이 server process(또는 prepared transaction) 하나당 담을 수 있는 객체 lock 수를 정한다.
이름과 달리 transaction 하나의 절대 상한이 아니라 평균치 개념이라, 전체 lock 테이블에 여유가 있는 한 개별 transaction은 이보다 많은 객체를 lock할 수 있다. row lock 수와는 무관하다 — lock할 수 있는 row 수에는 제한이 없다.
기본값 64는 역사적으로 대부분의 워크로드에 충분했지만, 한 transaction에서 많은 테이블을 건드리는 쿼리가 있다면 올려야 할 수 있다. 자식 테이블이 많은 부모 테이블을 조회하는 경우가 대표적이다. 서버 시작 시에만 설정할 수 있고, standby 서버에서는 primary와 같거나 더 큰 값이어야 한다. 그렇지 않으면 standby에서 쿼리가 허용되지 않는다.
운영 노트: 파티션 수가 많은 테이블을 통째로 조회하거나
pg_dump처럼 많은 객체를 한 번에 lock하는 작업에서 “out of shared memory” 에러가 나면 이 값이 부족한 신호다. 값을 올리려면 재시작이 필요하므로, 파티셔닝을 많이 쓰는 환경이라면 미리 여유 있게 잡아두는 편이 낫다.출처: PostgreSQL 18 문서