2010-06-28 6 views
3

저는 파이썬과 psycopg2를 사용하여 많은 쿼리를 실행하고 있습니다. 나는 하나의 커다란 임시 테이블을 만들거나, 약 2 백만 행을 만들고 나서, cur.fetchmany(1000)을 사용하여 한 번에 1000 행을 얻고, 그 행들을 포함하는 더 광범위한 쿼리를 실행한다. 광범위한 쿼리는 자급 자족합니다. 일단 완료되면 다음 1000 단계로 넘어갈 때 더 이상 결과가 필요하지 않습니다.postgresql : 공유 메모리가 부족합니까?

그러나 약 1000000 행은 psycopg2에서 예외가 있습니다.

psycopg2.OperationalError: out of shared memory 
HINT: You might need to increase max_locks_per_transaction. 

재미있게도 충분히 광범위한 쿼리가 생성 된 임시 테이블을 삭제하기 위해 쿼리를 실행했을 때 이런 일이 발생했습니다.

왜 이런 일이 발생할 수 있습니까? 그것을 피할 수있는 방법이 있습니까? 이 일이 중간에 일어난 것은 짜증나, 다시 말해야 만합니다. max_locks_per_transaction은 무엇을해야합니까?

참고 : 나는 .commit()을 수행하고 있지는 않지만 작성한 임시 테이블을 모두 삭제하고 있으며 각 "광범위한"트랜잭션에 대해 동일한 5 개의 테이블 만 만지기 때문에 테이블 잠금이 부족하면 문제가 될 수 있습니다.

답변

0

글쎄, 전체 트랜잭션을 하나의 트랜잭션으로 실행하고 있습니까? 이것은 아마 문제를 설명 할 것입니다. 테이블을 떨어 뜨릴 때 일어난 것만으로는 아무 것도 의미하지 않을 것입니다. 그것은 자유 잠금 장치가 없어지는 시점 일 수 있습니다.

뷰를 사용하면 임시 테이블의 대안이 될 수 있으며,이 항목을 만든 다음 즉시 제거하면 내 첫 번째 선택에서 분명히 알 수 있습니다.

+0

트랜잭션을 커서 및 .commits로 어떻게 변환합니까? 나는 어떤 .commit도하지 않았지만 쿼리를 위해 새로운 커서를 사용했다. – Claudiu

2

테이블을 만들 때 트랜잭션이 끝날 때까지 독점적으로 잠급니다. 그럼에도 불구하고 당신이 가서 그것을 버리십시오. 나는 텍사스를 시작하고 임시 테이블을 만들 경우

그래서 :

나는 테이블에 놓을 때이 '관계'잠금 장치가 제거되지 않습니다
[email protected]@[local] *=# create temp table foo(foo_id int); 
CREATE TABLE 
[email protected]@[local] *=# select * from pg_locks where pid = pg_backend_pid(); 
    locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid |  mode   | granted 
---------------+----------+-----------+------+-------+------------+---------------+---------+-----------+----------+--------------------+-------+---------------------+--------- 
virtualxid |   |   |  |  | 2/105315 |    |   |   |   | 2/105315   | 19098 | ExclusiveLock  | t 
transactionid |   |   |  |  |   |  291788 |   |   |   | 2/105315   | 19098 | ExclusiveLock  | t 
relation  | 17631 |  10985 |  |  |   |    |   |   |   | 2/105315   | 19098 | AccessShareLock  | t 
relation  | 17631 | 214780901 |  |  |   |    |   |   |   | 2/105315   | 19098 | AccessExclusiveLock | t 
object  | 17631 |   |  |  |   |    | 2615 | 124616403 |  0 | 2/105315   | 19098 | AccessExclusiveLock | t 
object  |  0 |   |  |  |   |    | 1260 |  16384 |  0 | 2/105315   | 19098 | AccessShareLock  | t 
(6 rows) 

: 사실

[email protected]@[local] *=# drop table foo; 
DROP TABLE 
[email protected]@[local] *=# select * from pg_locks where pid = pg_backend_pid(); 
    locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid |  mode   | granted 
---------------+----------+-----------+------+-------+------------+---------------+---------+-----------+----------+--------------------+-------+---------------------+--------- 
virtualxid |   |   |  |  | 2/105315 |    |   |   |   | 2/105315   | 19098 | ExclusiveLock  | t 
object  | 17631 |   |  |  |   |    | 1247 | 214780902 |  0 | 2/105315   | 19098 | AccessExclusiveLock | t 
transactionid |   |   |  |  |   |  291788 |   |   |   | 2/105315   | 19098 | ExclusiveLock  | t 
relation  | 17631 |  10985 |  |  |   |    |   |   |   | 2/105315   | 19098 | AccessShareLock  | t 
relation  | 17631 | 214780901 |  |  |   |    |   |   |   | 2/105315   | 19098 | AccessExclusiveLock | t 
object  | 17631 |   |  |  |   |    | 2615 | 124616403 |  0 | 2/105315   | 19098 | AccessExclusiveLock | t 
object  | 17631 |   |  |  |   |    | 1247 | 214780903 |  0 | 2/105315   | 19098 | AccessExclusiveLock | t 
object  |  0 |   |  |  |   |    | 1260 |  16384 |  0 | 2/105315   | 19098 | AccessShareLock  | t 
(8 rows) 

를, 그것은 추가 두 번 더 자물쇠가 ... 내가 계속해서 그 임시 테이블을 만들거나 삭제하면 매번 3 개의 잠금이 추가되는 것 같습니다.

그래서 나는이 모든 테이블이 트랜잭션 전반에 걸쳐 추가/삭제되는 것에 대처하기에 충분한 잠금 장치가 필요할 것이라고 생각합니다. 또는 쿼리간에 임시 테이블을 다시 사용하고 모든 임시 데이터를 제거하기 위해자를 수 있습니다.

2

동일한 이름을 가진 여러 세이브 포인트를 해제하지 않고 작성 했습니까?

SAVEPOINT savepoint_name을 반복적으로 실행하지만 해당하는 RELEASE SAVEPOINT savepoint_name 문을 실행하지 않은 채로 these instructions을 수행했습니다. PostgreSQL은 구형 세이브 포인트를 마스킹하는 것이 었습니다. 그것은 자물쇠를위한 기억이 다 떨어질 때까지 각각을 추적했다. 내 postgresql 메모리 제한을 훨씬 낮게 생각, 그것은 단지 ~ 10,000 저장 점이 나를 max_locks_per_transaction 칠했다.

관련 문제