Andreas Rieke <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
