Re: Reference Leak with type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reference Leak with type
Date
Msg-id 2224243.1617989447@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reference Leak with type  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Reference Leak with type  (Zhihong Yu <zyu@yugabyte.com>)
List pgsql-hackers
Michael Paquier <michael@paquier.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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SQL-standard function body
Next
From: James Coleman
Date:
Subject: Processing btree walks as a batch to parallelize IO