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
We are having terrible performance issues with a production instance of
PostgreSQL version 7.4.5, but are struggling with which parameters in
the postgresql.conf to change.
Our database server is an Apple G5 (2 x 2GHz CPU, 2GB RAM). The
operating system is Mac OS X 10.3.
The database seems t
