I wrote:
> I'm finally getting back to looking at the problem of reference-counting
> cached TupleDescs as was discussed in January. I had objected to the
> last patch Neil posted:
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00243.php
> on the grounds that it seemed too complicated.
I'm finally getting back to looking at the problem of reference-counting
cached TupleDescs as was discussed in January. I had objected to the
last patch Neil posted:
http://archives.postgresql.org/pgsql-patches/2006-01/msg00243.php
on the grounds that it seemed too complicated. On looking at it
c
On Sun, 2006-01-22 at 13:43 -0500, Tom Lane wrote:
> I object ... this is still trying to enforce tupdesc refcounting on much
> more of the system than I think useful or prudent.
Well, the patch adds management of TupleDesc refcounts solely for the
return value of lookup_rowtype_tupdesc(). If we'r
Neil Conway <[EMAIL PROTECTED]> writes:
> Attached is a revised patch: all the regression tests patch, and I'm not
> aware of any major remaining issues. Barring any objections, I'll apply
> this tomorrow.
I object ... this is still trying to enforce tupdesc refcounting on much
more of the system
On Thu, 2006-01-19 at 04:14 -0500, Neil Conway wrote:
> The patch is WIP: a few regression tests fail due to TupleDesc leaks I
> haven't fixed yet but that should be easily fixable, and there are a few
> other minor issues to address. I'm just posting the patch now to get any
> feedback.
Attached
Neil Conway <[EMAIL PROTECTED]> 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 wit
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 refco
Neil Conway <[EMAIL PROTECTED]> writes:
> ... However, since we're primarily
> concerned with TupleDescs allocated in CacheMemoryContext and that
> context is never reset, we can use the reference count *just* to manage
> the "external" references to TupleDescs. That should make the patch far
> les
On Sun, 2006-01-15 at 12:08 -0500, Tom Lane wrote:
> My inclination at this point is to forget the whole thing and just patch
> the callers of lookup_rowtype_tupdesc that need to copy the tupdesc.
Actually, I think I finally understand how to implement this patch
sanely. I had thought that the lif
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2006-01-12 at 10:40 -0500, Tom Lane wrote:
>> If you're finding yourself writing a large and invasive patch, I think
>> you're doing it wrong.
> I think I might be :-)
Yipes ... this seems far more invasive than I think is justified.
In particular
Neil Conway <[EMAIL PROTECTED]> writes:
> 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 Tu
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 b
Neil Conway <[EMAIL PROTECTED]> 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 structur
13 matches
Mail list logo
