From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | TupleDesc refcounting |
Date: | 2006-01-10 22:41:04 |
Message-ID: | 1136932864.26329.17.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Attached is a WIP patch that adds reference counting for TupleDescs. Two
issues that I ran into while implementing it:
(1) How should the lifetime of a TupleDesc be managed? The existing
ResourceOwner stuff seems to assume that it is managing "per-query"
resources. A TupleDesc will often live beyond the lifetime of a single
transaction, and might even be created before transactions can be
started (e.g. formrdesc() in relcache.c, when we're creating relcache
entries for nailed-in-cache relations early in InitPostgres()).
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...
(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.
Thoughts?
-Neil
Attachment | Content-Type | Size |
---|---|---|
tdesc_refcount-2.patch | text/x-patch | 22.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-10 23:05:54 | Re: TupleDesc refcounting |
Previous Message | Josh Berkus | 2006-01-10 21:14:31 | Re: Question about Postgresql time fields(possible bug) |