From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Rohit Bhogate <rohit(dot)bhogate(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reference Leak with type |
Date: | 2021-04-09 17:30:47 |
Message-ID: | 2224243.1617989447@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Tue, Apr 06, 2021 at 11:09:13AM +0530, Rohit Bhogate wrote:
>> I found the below reference leak on master.
> Thanks for the report. This is indeed a new problem as of HEAD,
Just for the record, it's not new. The issue is (I think) that
the tupledesc refcount created by get_cached_rowtype is being
logged in the wrong ResourceOwner. Other cases that use
get_cached_rowtype, such as IS NOT NULL on a composite value,
reproduce the same type of failure back to v11:
create type float_rec_typ as (i float8);
do $$
declare
f float_rec_typ := row(42);
r bool;
begin
r := f is not null;
commit;
end
$$;
WARNING: TupleDesc reference leak: TupleDesc 0x7f5f549809d8 (53719,-1) still referenced
ERROR: tupdesc reference 0x7f5f549809d8 is not owned by resource owner TopTransaction
Still poking at a suitable fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2021-04-09 17:33:31 | Processing btree walks as a batch to parallelize IO |
Previous Message | Andrew Dunstan | 2021-04-09 16:32:21 | Re: SQL-standard function body |