Re: beta1 & beta2 & Windows & heavy load

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Schuchardt <daniel_schuchardt(at)web(dot)de>
Cc: swm(at)linuxworld(dot)com(dot)au, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: beta1 & beta2 & Windows & heavy load
Date: 2004-09-12 16:50:28
Message-ID: 16701.1095007828@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

The shared memory should be freed on failure, though. Is that part
reproducible with current sources?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-09-12 17:40:02 pgindent vs try/catch
Previous Message Daniel Schuchardt 2004-09-12 16:40:57 Re: beta1 & beta2 & Windows & heavy load