먼저 내용이.좀 기네요...ㅠ 양해부탁드립니다...

DB는 postgres9.6버전을 사용하고 Replication 구성(streaming)으로 master-slave1-slave2 로 구성되어있습니다

두번의 서비스지연이 발생했는데 

첫번째는 지연 발생 후 master서버 모니터링 시  특정 프로시저에서 long이 잡히고 wait에 빠지는 현상이 있었습니다 ( 특정 프로시저의 경우 평균 30초내에 수행이완료되는 프로시저이나 지연발생당시 십수분이.지나도 처리되지 않고 wait에 빠지고 있었습니다. ) Slave서버들은 특이사항 없었음

해서 결국엔 master서버에 wait걸린 세션들은 모두 킬하여 해소하였습니다

***문제는 두번째 입니다. 서비스지연이 길어져 장애발생으로 이어진날인데

시작은 첫번째와 동일하게 서비스지연이 있다고 연락을 받았습니다

다만 약간 다른점은 이때는 서비스지연 연락을 받음과 동시에 slave1서버에서 알람이 발생했다고 전달받은 상태였습니다

이후 처음에 master서버를 확인했을 당시 첫번째 지연이 발생했던 날과 동일하게 특정 동일 프로시저수행세션이 처리되지 않고 wait에 빠져있었습니다

그래서 해당 세션들을 마찬가지로 정리를 했으나 서비스 지연은 계속 발생했었고 

다음으로 slave서버를 확인하자 아주 많은 세션들이 wait에 걸려있었습니다

급한 상황이라 먼저 ap에 이야기 후 wait 세션들을 모두 정리한 후에야 지연해소가 되었습니다

--------‐------------------------------------------------------------------

얘기가.길어졌는데 

***여기서 궁금한 것이 첫번째 지연당시와 달리 두번째 장애발생때는

Slave1 서버에 다수 wait이 걸리게 되었는지(master서버에서 특정프로시저를 수행하는 wait이 걸린 세션을 킬한것과 관련이 있는지..???.)

지연발생 당시 slave1서버 모니터링 시 가장 오래돌고 있는 세션이

idle in transaction에 걸려있는 상태인데 일반계정으로 postgres 내부카탈로그정보( pg_proc 프로시저관련 테이블) 를 조회하고 있었고

그 뒤에 들어오는 세션들이 모두 wait에 걸리게 되었습니다

세션들은 서비스에서 사용되는 세션도 일부 있었고 

세션이 끊어지지 않게하기 위한 show isolation level 세션들도 있었습니다...

****그런데 왜 Wait에 걸리게 된건지 이유가 궁금하네요

master서버에서 프로시저 킬수행한것과 관련이 있다면 첫번째 날에도 동일한 현상이 발생했을텐데 첫번째 날에는 slave서버는 특이사항이 없었습니다...

***** 그리고 slave서버에서 일반계정으로 pg_proc이 조회됐던것이 직접수행하지 않고 가능한 것인지요? ( 프로시저를 수행하는 세션이 wait에 빠지게 돼서 자동으로 내부 카탈로그 정보를 일반계정이 조회하는지....??? )

***마지막으로 건들면 안되는 테이블(pg_proc)을 일반유저가 조회해서  그 이후에 들어온 세션들이 모두 wait에 걸리게 된 것인지 궁금합니다..