From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Life cycles of tuple descriptors |
Date: | 2021-12-15 01:58:32 |
Message-ID: | 61B94BC8.6090709@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/14/21 20:02, Tom Lane wrote:
> The API contract for lookup_rowtype_tupdesc specifies that you must "call
> ReleaseTupleDesc or DecrTupleDescRefCount when done using the tupdesc".
> It's safe to assume that the tupdesc will stick around as long as you
> haven't done that.
I think what threw me was having a function whose API contract mentions
reference counts, but that sometimes gives me things that don't have them.
But I guess, making the between-the-lines of the contract explicit,
if lookup_rowtype_tupdesc is contracted to give me a tupdesc that sticks
around for as long as I haven't called ReleaseTupleDesc, and it sometimes
elects to give me one for which ReleaseTupleDesc is a no-op, the contract
is still that the thing sticks around for (at least) as long as I haven't
done that.
Cool. :)
Oh, hmm, maybe one thing in that API comment ought to be changed. It says
I must call ReleaseTupleDesc *or* DecrTupleDescRefCount. Maybe that dates
from before the shared registry? ReleaseTupleDesc is safe, but anybody who
uses DecrTupleDescRefCount on a lookup_rowtype_tupdesc result could be
in for an assertion failure if a non-refcounted tupdesc is returned.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-12-15 02:14:38 | Re: Life cycles of tuple descriptors |
Previous Message | Michael Paquier | 2021-12-15 01:47:24 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |