On 17.5.2014 22:33, Tomas Vondra wrote:
> On 17.5.2014 21:31, Andres Freund wrote:
>> On 2014-05-17 20:41:37 +0200, Tomas Vondra wrote:
>>> On 17.5.2014 19:55, Tom Lane wrote:
>>>> Tomas Vondra <tv@fuzzy.cz> writes:
>>> The tests are already running, and there are a few postgres processes:
>>>
>>> PID VIRT RES %CPU TIME+ COMMAND
>>> 11478 449m 240m 100.0 112:53.57 postgres: pgbuild regression [local]
>>> CREATE VIEW
>>> 11423 219m 19m 0.0 0:00.17 postgres: checkpointer process
>>> 11424 219m 2880 0.0 0:00.05 postgres: writer process
>>> 11425 219m 5920 0.0 0:00.12 postgres: wal writer process
>>> 11426 219m 2708 0.0 0:00.05 postgres: autovacuum launcher process
>>> 11427 79544 1836 0.0 0:00.17 postgres: stats collector process
>>> 11479 1198m 1.0g 0.0 91:09.99 postgres: pgbuild regression [local]
>>> CREATE INDEX waiting
>>>
>>> Attached is 'pmap -x' output for the two interesting processes (11478,
>>> 11479).
>>
>> Could you gdb -p 11479 into the process and issue 'p
>> MemoryContextStats(TopMemoryContext)'. That should print information
>> about the server's allocation to its stderr.
And another memory context stats for a session executing CREATE INDEX,
while having allocated The interesting thing is there are ~11k lines
that look exactly like this:
pg_namespace_oid_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used
Seems a bit strange to me.
Tomas
