Re: query against pg_locks leads to large memory alloc

On Mon, Aug 18, 2014 at 2:21 PM, Matheus de Oliveira
<matioli(dot)matheus(at)gmail(dot)com> 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(at)gmail(dot)com> 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