Re: Reference Leak with type

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

In response to

Responses

Browse pgsql-hackers by date

  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