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.
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:
> 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
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 noth
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
