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

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-10 23:05:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)com> writes:
> (1) How should the lifetime of a TupleDesc be managed? The existing
> ResourceOwner stuff seems to assume that it is managing "per-query"
> resources.

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.

You could conceivably set up a "cache ResourceOwner" with indefinite
lifespan to make the cache case more like the local-variable case,
but I think this would merely be a performance drag with no real value.
There's no point in a ResourceOwner if it will never be called on to
release resources, and a cache-lifespan ResourceOwner wouldn't be.

> In current sources, the lifetime of a TupleDesc is the lifetime of the
> memory context in which it is allocated (and/or whenever FreeTupleDesc()
> is invoked). We could imitate that behavior by optionally linking a
> ResourceOwner with each MemoryContext, and releasing the ResourceOwner
> when the MemoryContext is reset or deleted. However, I'm not sure that
> that's the right approach...

No.  We really only need this mechanism for the case where a tupledesc
allocated in a long-lived context (again, think relcache or typcache)
is going to be dynamically referenced by shorter-lived code.  Tying it
to MemoryContexts won't help because CacheMemoryContext never gets

> (2) The existing ResourceOwner users issue a warning if the resource
> they are managing is not explicitly released before a transaction
> successfully commits (so they elog(WARNING)). I don't see the need to be
> that strict for TupleDescs -- as we do with palloc() without a matching
> pfree(), I think it should be okay to just silently clean up "leaked"
> TupleDescs when releasing a ResourceOwner.

The reason why those warnings are issued is to catch code that is
failing to manage references properly.  I think that motivation applies
perfectly well to tuple descriptors too.  There is no good reason for
code to forget to release the descriptor reference in non-error paths.

No time to look at the patch itself right now ...

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Jim C. NasbyDate: 2006-01-11 00:09:51
Subject: Re: [PATCHES] Summary table trigger example race condition
Previous:From: Neil ConwayDate: 2006-01-10 22:41:04
Subject: TupleDesc refcounting

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