Martijn,
> Are you sure you're looking at the right numbers? Disk cache should be
> counted as part of free memory, for example.
I am the guy who posted the problem to mod_perl, and yes, I am quite
sure that we are talking about the right numbers. The best argument is
that the machine in fact sta
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 bu
Fred,
Fred Tyler wrote:
> Tonight I am going to upgrade postgres on the first machine and see if
> it makes any difference, but it'll be about a week before I know for
> sure if memory is still being lost (it's such a slow leak that you
> cannot tell with just a couple days).
I use the latest 8.
Fred,
>
> What is your kernel version?
It's 2.6.13-15. Thus, if we have a kernel bug, the newest known leaky
version is 2.6.13-15, whereas the oldest fixed version should be 2.6.16.27.
As many people run pg on older kernel versions, I would expect many
others having memory problems in that case.
Hi there,
maybe anyone can help me with the following problem.
Using PostgreSQL 7.03 on a Suse 6.3 Linux (kernel 2.2.13) with a P3/550
MHz,
I get a performance problem with a select command which takes up to 10
seconds.
The following tables are involved in this command:
CREATE TABLE "property_li
