LAG·LEAD 계산 범위 조정 ,트랜잭션 락 진단

About this offer

예전에 노션에 작성했던 문제 해결 과정 옮기는중이다 .. LAG·LEAD 계산 범위 조정을 통한 이전·다음 항목 조회 개선 상세 화면에서 LAG와 LEAD로 이전·다음 항목을 조회했으나, 인접 항목 정보가 정상적으로 조회되지 않았습니다. 윈도우 함수를 계산하는 쿼리 내부에서 특정 ID를 먼저 필터링하여 계산 대상이 한 행으로 제한되었습니다. 따라서 이전·다음 행이 윈도 함수의 계산 범위에서 제외되었습니다. 내가 적용한 해결 방식 내부 서브쿼리에서는 목록에 포함될 공통 조건과 정렬 기준을 적용하여 이전·다음 항목을 계산하고, 외부 쿼리에서는 특정 ID에 해당하는 결과만 선택하도록 수정했습니다. 핵심 코드 또는 원칙 실제 테이블 대신 가상 데이터로 재구성한 SQL 예시입니다. WITH sample_items (item_id) AS ( VALUES (10), (20), (30) ), navigation AS ( SELECT item_id, LAG(item_id) OVER ( ORDER BY item_id ) AS previous_id, LEAD(item_id) OVER ( ORDER BY item_id ) AS next_id FROM sample_items ) SELECT item_id, previous_id, next_id FROM navigation WHERE item_id = 20; -- 결과 -- item_id = 20 -- previous_id = 10 -- next_id = 30 목록 범위를 결정하는 조건은 윈도 함수 계산 전에 적용합니다. 특정 상세 항목을 선택하는 조건은 계산 후 외부에서 적용합니다. 윈도 함수의 계산 범위와 상세 조회 조건을 분리하여 이전·다음 항목 정보가 누락되는 쿼리 구조를 개선했습니다. ** PostgreSQL 시스템 뷰를 활용한 트랜잭션 락 진단** 문제 상황 트랜잭션 실행 중 락으로 인해 작업이 대기하는 상황에서 관련 세션과 실행 상태를 확인할 필요가 있었습니다. 작업 지연 현상만으로는 락 대기 여부와 관련 세션을 파악하기 어려웠습니다. 락 획득 상태와 세션 정보를 함께 조회하여 조사 범위를 좁혀야 했습니다. 원문에는 락을 유지하게 된 개별 트랜잭션의 최종 원인이나 조치 결과가 기록되어 있지 않아, 이 사례는 진단 과정 중심으로 정리했습니다. pg_locks와 pg_stat_activity를 PID 기준으로 연결하여 락 유형, 모드, 획득 여부와 세션의 실행 SQL·시작 시각·상태를 확인하는 조회 SQL을 정리했습니다. 대기 중인 락과 특정 대상의 관련 PID를 확인하는 조건을 구분하여, 상황에 따라 조회 범위를 좁힐 수 있도록 구성했습니다. 핵심 코드 또는 원칙 아래는 원문의 조회 방향을 단순화한 예시입니다. 업무 테이블명이나 실제 SQL 내용이 결과에 노출되지 않도록 대상 테이블명과 query 컬럼을 제외했습니다. pg_locks와 pg_stat_activity는 PostgreSQL 표준 시스템 뷰입니다. SELECT a.pid, l.locktype, l.mode, l.granted, a.state, a.query_start FROM pg_locks AS l JOIN pg_stat_activity AS a ON a.pid = l.pid WHERE l.granted = false ORDER BY a.query_start; granted = false는 락 획득을 기다리는 상태입니다. 대기 세션을 락 보유 세션으로 단정하지 않습니다. 조회 자체는 락을 해제하지 않으며, 상태 확인과 세션 종료는 별도 조치입니다.

Offer details

Provider

velog

Source

velog-rss

Score

54.4

Confidence

49%