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

From Tom Lane
Subject Re: beta1 & beta2 & Windows & heavy load
Date
Msg-id 16701.1095007828@sss.pgh.pa.us
Whole thread Raw
In response to beta1 & beta2 & Windows & heavy load  (Daniel Schuchardt <daniel_schuchardt@web.de>)
Responses Re: beta1 & beta2 & Windows & heavy load  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Indexed views?
Next
From: Tom Lane
Date:
Subject: pgindent vs try/catch