Re: Reference Leak with type

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reference Leak with type
Дата
Msg-id 2224243.1617989447@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reference Leak with type  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Reference Leak with type
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: SQL-standard function body
Следующее
От: James Coleman
Дата:
Сообщение: Processing btree walks as a batch to parallelize IO