Re: beta1 & beta2 & Windows & heavy load - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: beta1 & beta2 & Windows & heavy load
Date
Msg-id 200409122223.i8CMNMr26413@candle.pha.pa.us
Whole thread Raw
In response to Re: beta1 & beta2 & Windows & heavy load  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: beta1 & beta2 & Windows & heavy load  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Daniel Schuchardt <daniel_schuchardt@web.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: oid2name
Next
From: Bruce Momjian
Date:
Subject: Re: oid2name