Skip to content

PostgreSQL 호환성 전수검사 ​

요약 ​

ProcessCenter는 PostgreSQL provider와 PostgreSQL schema·migration을 갖추고 있으나 일부 저장 경로가 MySQL 결과 객체와 upsert API에 의존하고 있었다.

수정 완료 ​

server/db-connection.ts에 getAffectedRowCount, insertReturningId, dialectUpsert를 추가했다. PostgreSQL의 rowCount와 MySQL의 affectedRows를 공통 처리하고, PostgreSQL identity는 returning()으로 회수한다. 디렉터리 동기화의 상태·조직·사용자 upsert와 사용자 upsert를 방언별로 분리했다. approval policy·organization·terminology 생성의 PostgreSQL identity 회수도 보정했다.

전수검사 결과 ​

영역상태비고
DB provider양호`DATABASE_DIALECT=mysql
PostgreSQL schema양호MySQL export와 table export parity 확인
PostgreSQL migration양호baseline과 runtime settings migration 존재
affectedRows수정 완료repository 삭제·optimistic lock 경로를 공통 함수로 전환
insertId핵심 생성 경로 수정PostgreSQL returning() 분기 적용
동기화 upsert수정 완료상태·조직·사용자에 conflict target 지정
기타 upsert확인 완료서버 호출부의 MySQL 전용 upsert는 제거했고 공통 helper 내부에만 방언별 API가 남아 있음
Advisory lock수정 완료PostgreSQL pg_try_advisory_xact_lock과 MySQL GET_LOCK을 방언별로 분리
Raw execute 결과수정 완료PostgreSQL QueryResult.rows를 RAG 검색 결과로 올바르게 추출

추가 수정 내역 ​

초기 기동 경로에서 실행되는 프로세스 코드 정규화가 공통 advisory lock 유틸리티를 호출하면서 PostgreSQL에서도 MySQL 전용 GET_LOCK()을 실행하던 문제를 확인했다. PostgreSQL에서는 트랜잭션 종료와 함께 해제되는 pg_try_advisory_xact_lock(hashtext(...))을 사용하도록 분기했으며, MySQL의 RELEASE_LOCK() 동작은 유지했다.

또한 PostgreSQL의 node-postgres 기반 execute() 결과는 { rows } 형태인데, private RAG 검색 경로가 MySQL식 배열 결과만 처리하고 있었다. 해당 경로가 QueryResult.rows와 MySQL 배열 응답을 모두 처리하도록 보정했다.

남은 위험 ​

server/db-connection.ts의 MySQL 전용 legacy schema repair는 PostgreSQL에서 의도적으로 실행하지 않는다. PostgreSQL 운영 DB는 별도 drizzle/postgres-migrations를 반드시 적용해야 한다. 모든 배포 환경에서 DATABASE_DIALECT와 DATABASE_URL을 함께 지정해야 하며, 둘이 불일치하면 schema와 driver가 다른 방언으로 실행될 수 있다.

검증 ​

TypeScript 검사와 production build는 통과했다. advisory lock 테스트는 PostgreSQL 분기를 포함해 3개 모두 통과했다. 전체 테스트는 기존 클라이언트 테스트 12건이 실패했으며, 실패 영역은 TaskFlowMap의 auth mock 누락과 Home의 기존 ProcessCenter 텍스트 계약으로 DB 방언 수정과 무관하다.