Re: beta1 & beta2 & Windows & heavy load

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: beta1 & beta2 & Windows & heavy load
Дата
Msg-id 200409122223.i8CMNMr26413@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: beta1 & beta2 & Windows & heavy load  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: beta1 & beta2 & Windows & heavy load  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: oid2name
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: oid2name