From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Schuchardt <daniel_schuchardt(at)web(dot)de> |
Cc: | swm(at)linuxworld(dot)com(dot)au, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: beta1 & beta2 & Windows & heavy load |
Date: | 2004-09-12 16:50:28 |
Message-ID: | 16701.1095007828@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Schuchardt <daniel_schuchardt(at)web(dot)de> writes:
> 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.
Well, yes, it has to take a lock on the subtransaction XID, which will
be held until main transaction commit. I'm not sure we have much of a
choice about this --- although it does seem annoying to have a
shared-memory-size constraint on how many subtransactions you can have.
The shared memory should be freed on failure, though. Is that part
reproducible with current sources?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-12 17:40:02 | pgindent vs try/catch |
Previous Message | Daniel Schuchardt | 2004-09-12 16:40:57 | Re: beta1 & beta2 & Windows & heavy load |