Skip site navigation (1) Skip section navigation (2)

Re: TupleDesc refcounting

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: TupleDesc refcounting
Date: 2006-01-12 10:05:46
Message-ID: 1137060346.9143.144.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
On Tue, 2006-01-10 at 18:05 -0500, Tom Lane wrote:
> Yeah.  I was envisioning two different approaches: for TupleDesc
> references from long-lived data structures (ie, typcache or relcache)
> just increment or decrement the count when the referencing data
> structure changes.  ResourceOwner would be used for dynamic within-query
> references --- in practice, local variables.  If the reference would
> be forgotten during an elog longjmp then you need a ResourceOwner to
> backstop it, otherwise not.

Ah, I see what you mean. In implementing this, I wasn't sure the best
way to provide these two sorts of TupleDesc references. My first thought
was to add a "use ResourceOwner?" boolean parameter to the routines that
create and destroy references to TupleDescs:

extern TupleDesc CreateTemplateTupleDesc(int natts, bool hasoid,
                                         bool use_resowner);
extern TupleDesc CreateTupleDesc(int natts, bool hasoid,
                                 Form_pg_attribute *attrs,
                                 bool use_resowner);
extern TupleDesc CreateTupleDescCopy(TupleDesc tupdesc,
                                     bool use_resowner);
extern TupleDesc CreateTupleDescCopyConstr(TupleDesc tupdesc,
                                           bool use_resowner);
extern void IncrTupleDescRefCount(TupleDesc tupdesc,
                                  bool use_resowner);
extern void DecrTupleDescRefCount(TupleDesc tupdesc,
                                  bool use_resowner);

But that requires making *all* the call-sites of these routines care
about whether a ResourceOwner is being used. I think most call-sites
will want to use a ResourceOwner, so that ought to be the default.
Avoiding changing the function signatures also means we don't break a
fairly widely-used API. Instead, how about defining:

extern void IncrTupleDescPersistentRefCount(TupleDesc tdesc);

(the name could do with improvement). This would increment the
TupleDesc's "persistent reference count" -- that is, non-persistent
references are automatically released at transaction end, whereas
persistent ones are only released via:

extern void DecrTupleDescPersistentRefCount(TupleDesc tdesc);

One downside is that creating a new, persistent TupleDesc requires a
little pain:

TupleDesc tdesc = make_your_tdesc();
IncrTupleDescPersistentRefCount(tdesc);
DecrTupleDescRefCount(tdesc);

That means we will unnecessarily inform the ResourceOwner about the
TupleDesc, and then tell it to immediately forget about it. However, I
think that's acceptable: ResourceOwnerRememberTupleDesc() is trivial,
and ResourceOwnerForgetTupleDesc() searches beginning at the
most-recently-added TupleDesc, so it should also be very cheap.

-Neil



In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-01-12 15:40:43
Subject: Re: TupleDesc refcounting
Previous:From: Joachim WielandDate: 2006-01-12 09:51:32
Subject: patch to create system view that lists cursors

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group