From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Schuchardt <daniel_schuchardt(at)web(dot)de>, swm(at)linuxworld(dot)com(dot)au, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: beta1 & beta2 & Windows & heavy load |
Date: | 2004-09-12 22:23:22 |
Message-ID: | 200409122223.i8CMNMr26413@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
You mean 64 (the number of object locks)? Can you clarify why the
subtransaction is locked in this case and not others?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-09-12 22:32:40 | Re: oid2name |
Previous Message | Alvaro Herrera | 2004-09-12 22:16:27 | oid2name |