From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Life cycles of tuple descriptors |
Date: | 2021-12-15 02:14:38 |
Message-ID: | 609406.1639534478@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> 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.
That's supposed to be hidden under ReleaseTupleDesc; you shouldn't have to
think about it.
> 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.
Yeah, I was just wondering the same. I think DecrTupleDescRefCount
is safe if you know you are looking up a named composite type, but
maybe that's still too much familiarity with typcache innards.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-12-15 02:49:11 | Re: Skipping logical replication transactions on subscriber side |
Previous Message | Chapman Flack | 2021-12-15 01:58:32 | Re: Life cycles of tuple descriptors |