Andreas Rieke <andreas.rieke@xxxxxx> writes: > R1: First of all, I tried the loop from your older OS X problem: > while true > do > psql -c "select count(*) from tenk1" regression > done > Even after running the psql command for more than a million times over > quite a small table with about 10 000 entries, I can NOT see any lost > memory. Thus, we have another problem as the OS X people. OK, that kills the theory that the leak is triggered by subprocess exit. Another thing that would be worth trying is to just stop and start the postmaster a large number of times, to see if the leak occurs at postmaster exit. Also, do you have any problems with backends crashing (ie, forced database restarts)? That scenario should be equivalent to a postmaster restart, but it might be worth trying a few cycles of kill -9'ing a backend (not the postmaster) to check for a leak in that path. > R2: After having a look at the linux kernel mailing list, it seems that > this problem is not yet known there. It's premature to complain to them until we have a clearly reproducible way of causing the leak. > Q1: The first question is quite easy: Is there any way to tell pg NOT to > use shmem? No. > Does pg allocate other shmem blocks? No. regards, tom lane
