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?
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
