Managing a long-held TupleDesc reference

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Managing a long-held TupleDesc reference
Date: 2016-03-09 01:49:22
Message-ID: 56DF8122.20607@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

If that's an issue, what would be better? Should UDT not retain a
TupleDesc, but rather look it up with each use? (That would happen
in preparation for calling a Java function with a parameter or return
of that type, or when a Java function makes JDBC-SPI calls touching
that type.) Reading typcache.c, I get the impression that it may be
intended to be fast enough for such usage, and that it manages the
complexity of invalidating entries when something gets altered.

Should there be some intermediate solution where UDT does retain a
TupleDesc reference within a transaction, but certain callbacks are
registered to know when to release or refresh it?

Is there a canonical, preferred approach?

Thanks,
-Chap

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-09 01:56:29 Re: Managing a long-held TupleDesc reference
Previous Message Corey Huinker 2016-03-09 01:41:11 Re: Declarative partitioning