Re: TupleDesc refcounting - Mailing list pgsql-patches

From Neil Conway
Subject Re: TupleDesc refcounting
Date
Msg-id 1137303684.9145.24.camel@localhost.localdomain
Whole thread Raw
In response to Re: TupleDesc refcounting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TupleDesc refcounting  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
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 :-)

Attached is a revised version of the patch (still WIP). In summary:

- TupleDescs are allocated in TopMemoryContext, and released when their
reference count falls to zero.

- normal TupleDesc references are released automatically (with a
warning) when the ResourceOwner is released, but it is possible to
obtain a "persistent reference" to a TupleDesc that is only released
manually

- I've begun updating the code to reflect this, but I haven't finished
yet. Either the required changes are more extensive than expected or I'm
doing something wrong: adding reference counting for TupleDescs changes
the rules for TupleDesc lifetime. Plenty of code was doing stuff like:

/* we need this TupleDesc to live for a while */
old_cxt = MemoryContextSwitchTo(LongLivedContext);
tdesc = CreateTupleDescCopy(tdesc);
MemoryContextSwitchTo(old_cxt);

which no longer has the intended effect: the CurrentMemoryContext does
not control the lifetime of a TupleDesc. I've only begun to make the
required changes: the patch passes initdb, but fails during the
regression tests. I've done a cursory job of updating the relcache and
syscache to use the new refcounting rules, but I haven't really done the
executor, the utility commands, or the other miscellaneous parts of the
system that manipulate TupleDescs.

I believe most of the remaining work is a Small Matter of Programming:
updating code to use reference counts rather than depending on the
lifetime of the CurrentMemoryContext. However, if I'm going down the
wrong track, I thought I'd float the patch now rather than going further
down this path. Comments welcome.

-Neil


Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: ecpg: fix amd64 warning/bug
Next
From: Neil Conway
Date:
Subject: inferred param types for PREPARE