Hmmmm....are you running on RedHat 7.3? I'm not using any plpgsql,
triggers or foreignkeys. Very simple DB. I'm using the pre-compiled
RPM version of 7.3.2 on the production machine. I have a similar
environment setup running under Debian (woody), but that's a version
that I compiled from the source, and I can't really seem to duplicate
this behavior. Things are kinda moving around a bit, because I'm
switching from Struts DB pooling to the Postgresql driver JDBC2 pooling
mechanism as well (this is a live production server, and I gotta get
this thing fixed so I can get some sleep and stop having to babysit the
site), so I'm throwing everything I can think of at this. So here's the
main question:
During a large select/insert like this, the memory use of the pgsql
backend goes up, right? Is it supposed to go down afterwards? I just
need one fact to hang on to here to help me work this out. I think my
plan at this point is to compile 7.3.2 on redhat with a fresh install
and see how that behaves.
Thanks again, Tom. I appreciate your help.
/kurt
Tom Lane wrote:
> Kurt Overberg <kurt@hotdogrecords.com> writes:
>
>>Darn it, I knew I forgot something. I'm running on redhat 7.3, with
>>postgresql version 7.3.2, accessing it through tomcat 4.1.18. It
>>APPEARS that its the insert that bumps the memory. Here's the schema
>>for the member table:
>
>
> I created the two tables, loaded some dummy data into member, and
> inserted/selected like mad ... no sign of memory bloat. So there's
> something else involved here. Any plpgsql functions being used?
> Triggers or foreign keys?
>
> regards, tom lane
>
>
