53300은 포스트그레스가 최대 연결이 차서 새 클라이언트만 거절할 때 나는 코드입니다. pg_stat_activity에서 client backend를 세고, 서버리스는 인스턴스마다 풀이 늘어나므로 풀러나 connection_limit으로 줄입니다. 비밀번호 실패와 앱 풀 대기는 다른 줄입니다. PostgreSQL, Prisma, 버셀 프리뷰, 카카오 콜백, 한국 1인 개발. 2026년 9월 문서.
53300은 포스트그레스가 클라이언트 슬롯을 다 쓴 뒤 새 접속을 거절할 때 내는 코드입니다. 콘솔의 문장은 FATAL: sorry, too many clients already이고, 이미 붙어 있는 세션은 쿼리를 계속합니다.
버셀 프리뷰에서 카카오 콜백만 500이고, 대시보드 SQL은 열리는 자리가 여기입니다. 기본 max_connections는 보통 100이고, 그중 3칸은 슈퍼유저 예약입니다. 서버리스 함수가 프리즈마 풀을 인스턴스마다 열면 앱 역할 칸이 먼저 찹니다.
비밀번호를 돌리기 전에 pg_stat_activity에서 client backend만 세세요. 최대 연결을 올리는 변경은 서버를 다시 켜야 반영됩니다. 근거는 포스트그레스 연결 설정과 오류 코드 표입니다.
새 접속이 서버 슬롯을 받지 못하면 SQLSTATE는 53300, 이름은 too_many_connections입니다.
포스트그레스는 접속마다 백엔드 프로세스를 하나 띄웁니다. max_connections는 그 클라이언트 수의 상한이고, 기본값은 initdb가 커널을 보고 잡는데 보통 100입니다. 이 값은 서버를 시작할 때만 바뀝니다. 설정 파일을 고치고 리로드만 하면 예전 숫자가 남습니다.
이미 붙은 세션은 이 오류를 받지 않습니다. 거절은 문을 두드린 새 연결에게만 갑니다. 그래서 로컬에 열어 둔 테이블 도구는 살아 있고, 방금 뜬 프리뷰 함수만 죽습니다.
먼저 셀 것 | pg_stat_activity 전체 행 수에는 오토배큠 같은 보조 프로세스도 섞입니다. 슬롯과 비교할 숫자는 backend_type = 'client backend'입니다.
문장에 already가 있어도 원인 코드는 다섯 갈래로 갈립니다.
| 보이는 줄 | 의미 | 먼저 볼 곳 |
|---|---|---|
| 53300, too many clients | 서버 클라이언트 슬롯이 참 | pg_stat_activity의 client backend |
| 28P01 | 포트는 열렸고 그 역할의 비밀번호가 거절됨 | 역할 이름, 비밀번호 인코딩 |
| 프리즈마 P2024 | 앱 쪽 풀에서 빈 칸을 기다리다 시간 초과 | connection_limit, 풀 타임아웃 |
| ECONNREFUSED | 그 호스트의 그 포트가 연결을 안 받음 | 주소, 5432, 서비스 이름 |
| 57P01 | 관리자가 서버를 끄는 중 | 재시작 로그 |
P2024는 앱이 자기 풀에서 기다리다 포기한 줄입니다. 서버에는 아직 빈 슬롯이 있을 수 있습니다. 53300은 서버가 먼저 문을 닫은 줄입니다. 28P01은 문은 열렸는데 암호가 틀린 줄이라, 역할을 맞춰도 슬롯 수는 그대로입니다. 비밀번호 자리는 28P01 글에 따로 있습니다.
앱 역할이 거절당해도 슈퍼유저 칸이 남아 있으면 대시보드에서 아래를 실행할 수 있습니다.
예약 칸의 기본은 3입니다. 활성 접속이 max_connections - superuser_reserved_connections 이상이면 새 접속은 슈퍼유저만 받습니다. 복제 연결도 그때는 거절됩니다. 문서의 문장 그대로입니다.
상한과 클라이언트 세션만 세기SHOW max_connections; SHOW superuser_reserved_connections; SELECT count(*) FILTER (WHERE backend_type = 'client backend') AS clients, count(*) FILTER (WHERE state = 'active') AS active, count(*) FILTER (WHERE state = 'idle') AS idle, count(*) FILTER (WHERE state = 'idle in transaction') AS idle_in_txn FROM pg_stat_activity;
어느 앱이 몇 칸을 잡았는지SELECT application_name, usename, state, count(*) FROM pg_stat_activity WHERE backend_type = 'client backend' GROUP BY 1, 2, 3 ORDER BY count(*) DESC;
application_name이 비어 있으면 프리즈마나 테이블 도구가 이름을 안 넣은 것입니다. 연결 문자열에 application_name=preview-web처럼 붙여 두면 다음 거절 때 프리뷰와 로컬이 갈립니다.
유휴 트랜잭션은 쿼리가 없어도 슬롯을 붙잡습니다. 커밋이나 롤백 없이 함수가 끝나면 그 칸은 idle in transaction으로 남습니다. idle_in_transaction_session_timeout은 세션에서 SET 할 수 있는 상한입니다. 0이면 끄진 상태이고, 60초로 두면 그 세션은 롤백되며 칸을 돌려줍니다. 이 항목과 달리 max_connections는 시작 시에만 바뀝니다.
개발 서버에서는 저장할 때마다 클라이언트가 새로 생기면 로컬 슬롯도 찹니다. 프리즈마가 안내하는 싱글턴은 그 핫 리로드 복제를 막습니다.
버셀 함수는 인스턴스마다 메모리가 다릅니다. 싱글턴은 그 인스턴스 안에서만 하나를 유지합니다. 프리뷰가 10개 뜨고 각 풀이 10이면 앱만 100칸을 요구합니다. 기본 상한 100에서 예약 3을 빼면 앱 역할은 97 근처에서 53300을 만납니다.
서버리스에서 먼저 줄이는 숫자는 주소의 connection_limit입니다. 함수 하나당 1이면, 동시에 뜬 함수 수만큼만 서버 세션을 가져갑니다. 직접 포트 5432는 세션을 붙잡고, 트랜잭션 모드 풀러는 짧은 쿼리끼리 서버 세션을 나눠 씁니다. 풀러를 도입하는 설계 전체는 별도 글의 자리이고, 오늘은 거절이 난 뒤 세는 순서만 둡니다.
개발 서버용 싱글턴과 서버리스 한도const { PrismaClient } = require('@prisma/client') const globalForPrisma = globalThis const prisma = globalForPrisma.prisma || new PrismaClient() if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma module.exports = { prisma } // 서버리스 주소 예: 비밀번호는 로그에 찍지 않는다 // postgresql://USER:PASSWORD@HOST:5432/DB?connection_limit=1&application_name=preview-web
포스트그레스 커널 자원 문서는, 접속을 늘리기보다 max_connections를 낮추고 바깥 풀을 쓰는 편이 나은 경우가 많다고 적습니다. 접속마다 프로세스와 세마포가 늘기 때문입니다.
순서는 이렇습니다. 이름을 붙여 센 뒤, 유휴 트랜잭션 타임아웃을 두고, 함수당 풀을 1로 낮춥니다. 그다음에도 동시 함수가 상한을 넘으면 풀러를 끼우거나, 메모리가 받치는 범위에서만 상한을 올립니다.
| 순서 | 하는 일 | 반영 |
|---|---|---|
| 1 | client backend를 앱 이름별로 센다 | 조회만 |
| 2 | 유휴 트랜잭션 상한을 둔다 | 세션 SET 또는 설정 반영 |
| 3 | connection_limit을 함수당 1 근처로 | 다음 배포의 환경 변수 |
| 4 | 확인한 pid만 pg_terminate_backend | 그 세션만 종료 |
| 5 | 그래도 부족하면 상한 변경 | 서버 재시작 |
나이만 보고 유휴 세션을 한꺼번에 끊는 쿼리는 테이블 도구와 마이그레이션까지 자릅니다. pg_terminate_backend는 위에서 고른 pid에만 호출하세요. 슈퍼유저까지 53300이면 예약 3칸도 찬 것입니다. 그때는 재시작이나 OS에서 백엔드를 줄이는 쪽이 비밀번호 재발급보다 먼저입니다.
한국에서 혼자 프리뷰와 프로덕션과 노트북을 한 프로젝트 디비에 붙여 두면, 저녁에 콜백을 시험하는 순간 이 줄이 납니다. 콜백 주소를 고쳐도 슬롯 수는 그대로입니다.
내부 연계: 28P01 비밀번호 거절, 포트가 이미 잡힌 EADDRINUSE, 이름이 잠깐 안 풀리는 EAI_AGAIN.
인용한 기본값과 재시작 조건은 2026년 9월 29일 공개 문서 기준입니다.
슈퍼유저 예약이 기본 3칸입니다. 앱 역할은 상한에서 그 칸을 뺀 지점에서 거절되고, 슈퍼유저 세션은 남을 수 있습니다. 대시보드에서 client backend를 세면 됩니다.
이 값은 서버 시작 때만 읽습니다. 리로드 뒤에 SHOW가 옛 숫자면 프로세스를 다시 켜야 합니다. 재시작 전에 풀을 줄였는지 먼저 보세요.
P2024는 앱 풀 안에서 빈 연결을 기다리다 시간 초과입니다. 53300은 서버가 새 접속을 거절한 코드입니다. 서버 SHOW가 여유 있으면 P2024 쪽을 보고, 서버가 already를 찍으면 53300 쪽을 봅니다.
암호가 틀리면 28P01입니다. 53300은 슬롯 부족이라 암호를 맞춰도 칸이 생기지 않습니다. 세션을 줄이거나 예약 칸으로 들어가 조회하세요.
나이만으로 일괄 종료하면 마이그레이션과 테이블 도구까지 끊깁니다. application_name으로 고른 pid만 pg_terminate_backend에 넘기세요. 반복되면 타임아웃과 connection_limit이 먼저입니다.
싱글턴은 그 프로세스 안의 복제만 막습니다. 프리뷰 함수는 인스턴스마다 풀을 따로 엽니다. 주소의 connection_limit과 동시 함수 수를 곱해 상한과 비교하세요.
53300은 서버 클라이언트 슬롯이 차서 새 접속만 거절된 상태입니다. client backend를 세고, 유휴 트랜잭션과 함수당 풀을 줄인 뒤에 상한을 올리세요. 상한 변경은 재시작이 필요합니다. 관련 글: 28P01, 포트 점유, 일시적 이름 해석 실패.
프리뷰와 운영, 노트북이 데이터베이스 한 대를 같이 쓰면 빈 자리가 더 빨리 사라집니다. 관리 화면의 조회가 되는 동안 새 로그인만 거절되면, 관리자용으로 남겨 둔 칸은 아직 남아 있는 경우가 많습니다. 일반 역할이 거절되는 순간 붙은 세션부터 세고, 오래됐다고 한꺼번에 끊지 마세요. 일을 끝내지 않고 열린 작업을 먼저 닫은 뒤에 상한을 논의하면 재시작 횟수가 줄어듭니다.
