On Mon, Aug 18, 2014 at 2:21 PM, Matheus de Oliveira
<matioli.matheus@xxxxxxxxx> wrote:
> Do you really need such large values? What is your max_connections value?
max_connections = 450 ...we have found that we run out of shared
memory when max_pred_locks_per_transaction is less than 30k.
On Mon, Aug 18, 2014 at 2:29 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
> performance of any query to pg_locks is proportional to the setting of
> max_locks_per_transaction. still, something is awry here. can you
> 'explain' that query?
tudb=# explain SELECT mode, count(mode) AS count FROM pg_locks GROUP
BY mode ORDER BY mode;
QUERY PLAN
-------------------------------------------------------------------------------------
Sort (cost=0.63..0.65 rows=200 width=32)
Sort Key: l.mode
-> HashAggregate (cost=0.30..0.32 rows=200 width=32)
-> Function Scan on pg_lock_status l (cost=0.00..0.10
rows=1000 width=32)
(4 rows)
> SELECT COUNT(*) from pg_locks;
ERROR: invalid memory alloc request size 1562436816
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
