From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: ldap: fix resource leak |
Date: | 2006-11-05 23:43:05 |
Message-ID: | 1162770185.5692.341.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Sat, 2006-11-04 at 23:34 -0500, Tom Lane wrote:
> Perhaps use a PG_TRY construct?
At least for the existing code, this doesn't work well: the function
exits early via ereport(LOG) and then "return STATUS_ERROR;", so AFAICS
there isn't an easy way to simplify the existing error handling logic
via PG_TRY.
Note that this is related to a more general problem: if *any* backend
function allocates a resource that needs to be manually cleaned up, it
probably ought to be using a PG_TRY block. Otherwise, the resource will
be leaked on elog(ERROR). I wouldn't be surprised if various parts of
the backend neglected to get this right. However, in this particular
case, I didn't bother doing this, since it didn't seem likely that
anything we're going to invoke will report errors via elog. One could
make an argument for doing, for the sake of correctness/paranoia...
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-06 00:16:14 | Re: ldap: fix resource leak |
Previous Message | Tom Lane | 2006-11-05 23:42:27 | Re: Writing WAL for relcache invalidation:pg_internal.init |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-06 00:16:14 | Re: ldap: fix resource leak |
Previous Message | Tom Lane | 2006-11-05 23:42:27 | Re: Writing WAL for relcache invalidation:pg_internal.init |