Re: Managing a long-held TupleDesc reference

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Managing a long-held TupleDesc reference
Дата
Msg-id 28055.1457488589@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Managing a long-held TupleDesc reference  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> When PL/Java is told to map a PostgreSQL composite type to a certain
> Java class, on its first use of the type mapping it calls
> lookup_rowtype_tupdesc_noerror and then creates a PL/Java UDT structure
> that retains a reference to the TupleDesc. This seems to be what is leading
> to a TupleDesc reference leak warning at completion of the transaction.

> So I am wondering what a recommended way of managing these TupleDescs
> would be. I could use lookup_rowtype_tupdesc_copy before saving it in
> the UDT struct, and I assume that would silence the leak warning, but
> would that be asking for trouble if the composite type gets altered
> during the session and the saved TupleDesc is stale?

Probably, but holding a refcounted reference doesn't make that better.
If the typcache updates, it'll make a new TupleDesc and release its
own hold on the one you've got; it doesn't cause that one to change
in-place.

> If that's an issue, what would be better? Should UDT not retain a
> TupleDesc, but rather look it up with each use?

Probably the safest answer.  If you go through typcache then it will
avoid unnecessary recalculations of the type's tupdesc.  It means one
extra hashtable lookup per reference, but that's not that awful.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: WIP: Access method extendability
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.