From: | t-ishii(at)sra(dot)co(dot)jp |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Re: [PATCHES] Important 7.0.* fix to ensure buffers are released |
Date: | 2000-09-04 11:29:36 |
Message-ID: | 20000904202936D.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> I don't have 6.5.* running anymore to check, but it looked to me like
> elog out of an SQL function would result in refcount leaks. But the
> elog would have to occur while inside the function's recursive call
> to ExecutorRun, so your example (which will detect its error during
> query plan setup) doesn't exhibit the problem. Try something like
> select 1/0;
> inside the function.
Oh, I see.
> > Interesting thing is that the select in above case produces a
> > notice in 7.0.2 (with or without your patches):
>
> Yes, still there in current sources. The leak comes from the fact
> that the function's internal SELECT is never shut down because the
> function isn't run to completion. This is one of the things I think we
> need to fix during querytree redesign. However, 7.0 at least detects
> and recovers from the leak, which is more than can be said for 6.5.
Agreed.
> > while 6.5.3 does not. Maybe 6.5.3 failes to detect buffer leaks at
> > transaction commit time?
>
> In fact it does fail to detect them, in cases like this where the leak
> is attributable to an uncompleted query inside a function call. That's
> one of the things that was broken about the refcount save/restore
> mechanism...
Understood.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-09-04 12:02:46 | Re: RULE vs. SEQUENCE |
Previous Message | Karel Zak | 2000-09-04 11:16:45 | Re: RULE vs. SEQUENCE |
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-09-05 08:51:15 | RE: Important 7.0.* fix to ensure buffers are released |
Previous Message | Peter Mount | 2000-09-04 08:47:28 | RE: Charset encoding patch to JDBC driver |