Tom,
thanks for all the facts first.
Tom Lane wrote:
>If the shared segment is no longer present according to ipcs,
>and there are no postgres processes still running, then it's
>simply not possible for it to be postgres' fault if memory has
>not been reclaimed. So you're looking at a kernel bug.
>
>
>
Before we switch this item to the linux kernel mailing list, let me add
two results and two more questions.
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.
R2: After having a look at the linux kernel mailing list, it seems that
this problem is not yet known there.
So far, so good.
Q1: The first question is quite easy: Is there any way to tell pg NOT to
use shmem? Although I expect minor performance with that configuration,
I would like to try that out.
Q2: You say that pg allocates one shared memory block which is never
changed in size, and I can see with ipcs that we talk about 10 MBytes on
my machine (which uses the default configuration). Although I usually do
not kill -9 the postmaster, the maximum loss of memory seems to be 10 M
for that reason.
However, my machine looses between 500 M and 800 M in two weeks, and
within that time, I restart pg only very few times, say 3-4 times.
Does pg allocate other shmem blocks? If there is really a kernel memory
problem in shmem, how can I loose so much memory?
Thanks in advance,
Andreas
