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