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.
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.
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
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
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
