| 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: | Whole Thread | Raw Message | 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 |