From: | Daniel Schuchardt <daniel_schuchardt(at)web(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, swm(at)linuxworld(dot)com(dot)au |
Subject: | Re: beta1 & beta2 & Windows & heavy load |
Date: | 2004-09-12 16:40:57 |
Message-ID: | 41447C19.4020401@web.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane schrieb:
>
> Can you provide a concrete test case?
>
houres later I'v located the problem. Its not heavy load but
subtransactions in Triggers. It's very easy to recreate:
the problem is this Syntax :
CREATE OR REPLACE FUNCTION do_standard_mgc() RETURNS TRIGGER AS'
BEGIN
BEGIN
--prob also occurs in this case (empty subtransaction)
EXCEPTION
WHEN OTHERS THEN
PERFORN NULL;
END;
RETURN new;
END'LANGUAGE plpgsql;
It seems that this subtransactions allocates mem that is never freed. So
create a big table with such a trigger - func (in my case after insert
or update), do a begin and a update all over the table and postgres will
use more and more memory as long there is memory available and then abort.
I can post a sample script but i think it's easy to recreate this prob.
Hope that helps,
Daniel.
BTW : how to ignore only duplicate - unique key exceptions?
is there sth like WHEN dup_unique_key THEN?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-12 16:50:28 | Re: beta1 & beta2 & Windows & heavy load |
Previous Message | Peter Eisentraut | 2004-09-12 16:19:44 | Re: pgxs default installation + various fixes |