Re: beta1 & beta2 & Windows & heavy load

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

In response to

Responses

Browse pgsql-hackers by date

  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