The problem happened again this morning and I took the chance to check
out the locking situation. The number of locks increased dramatically up
to over 1000, but they were all AccessShareLocks and all were granted.
The odd RowExclusiveLock appeared but none persisted. On the basis
that nothing
Alexander Stanier [EMAIL PROTECTED] writes:
The problem happened again this morning and I took the chance to check
out the locking situation. The number of locks increased dramatically up
to over 1000, but they were all AccessShareLocks and all were granted.
The odd RowExclusiveLock
Looks as though there are several processes which are acquiring a load
of locks:
pid | count
--+---
3193 | 2
3192 | 9
3191 | 7
3190 | 3
3189 | 2
3188 | 3
3187 | 3
3186 | 3
3185 | 3
3184 | 3
3183 | 3
3182 |13
3181 | 3
3179 |10
3175
Alexander Stanier [EMAIL PROTECTED] writes:
Looks as though there are several processes which are acquiring a load
of locks:
13 locks isn't a load. I was worried about scenarios in which a
single process might take hundreds or thousands of locks; it doesn't
look like you have that.
Alexander Stanier [EMAIL PROTECTED] writes:
The database seems to fine to start with, but then as the load increases
it seems to reach a threshold where the number of non-idle queries in
pg_stat_activity grows heavily and we appear to get something similar to
a motorway tail back with up to