Re: TupleDesc refcounting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: TupleDesc refcounting
Date: 2006-01-19 16:35:57
Message-ID: 17069.1137688557@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Neil Conway <neilc(at)samurai(dot)com> writes:
> On Tue, 2006-01-17 at 09:36 -0500, Tom Lane wrote:
>> I suspect you'll find that it's convenient to treat typcache's own
>> link to a tupdesc as a reference count too, so it's not strictly
>> "external" references that should be counted.

> The problem with this is that incrementing a TupleDesc's refcount
> informs the CurrentResourceOwner.

Not if it's just "tupdesc->refcount++;" ... ;-)

Seriously, I was imagining a two-level structure where tupdesc itself
just has operations on the order of

refcount++;

if (--refcount <= 0)
FreeTupleDesc();

and then a separate layer on top of that adds ResourceOwner management.
This is precisely because the cache code requires non-resource-owner-
managed links (or at least, has no particular use for the services of a
ResourceOwner).

> There was some call-sites of lookup_rowtype_tupdesc() where it doesn't
> seem to be easy to use reference counting. For example, consider the
> implementation of get_expr_result_type(): some code paths within that
> function call lookup_rowtype_tupdesc() to produce the returned
> TupleDesc, and some do not. The easiest fix seemed to be just making a
> copy of the TupleDesc for the lookup_rowtype_tupdesc() cases.

Yeah, I noticed this while making the back-branch patch. I agree that
any given routine had better have a consistent return convention: if
the tupdesc needs to be refcount-decremented when done, that must be
the case in all code paths, since the caller can't be expected to know
which case applies. My recollection though is that the non-lookup cases
return freshly-built-in-local-storage tupdescs, which could certainly be
set up as having refcount 1 so that the decrement would work correctly.
It may or may not be worth the trouble compared to just copying, though.
You should think about whether a routine is a performance hotspot before
going out of your way to avoid a copy step.

> (Apologies for not getting this done earlier, I had a touch of the flu
> yesterday...)

There's no hurry about it. Hope you're feeling better.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2006-01-19 18:08:28 Re: Uninstall scripts for contrib
Previous Message David Fetter 2006-01-19 15:56:45 Re: Uninstall scripts for contrib