Re: beta1 & beta2 & Windows & heavy load

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?

In response to

Responses

Browse pgsql-hackers by date

  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