Re: beta1 & beta2 & Windows & heavy load
| От | Tom Lane |
|---|---|
| Тема | Re: beta1 & beta2 & Windows & heavy load |
| Дата | |
| Msg-id | 16701.1095007828@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | beta1 & beta2 & Windows & heavy load (Daniel Schuchardt <daniel_schuchardt@web.de>) |
| Ответы |
Re: beta1 & beta2 & Windows & heavy load
|
| Список | pgsql-hackers |
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.
The shared memory should be freed on failure, though. Is that part
reproducible with current sources?
regards, tom lane
В списке pgsql-hackers по дате отправления: