Re: Discontent with development process (was:Re: pgaccess - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: Discontent with development process (was:Re: pgaccess
Date
Msg-id 20020515004347.R75064-100000@mail1.hub.org
Whole thread Raw
In response to Re: Discontent with development process (was:Re: pgaccess - the discussion is over)  (Myron Scott <mkscott@sacadia.com>)
List pgsql-hackers
On Tue, 14 May 2002, Myron Scott wrote:

>
>
> Tom Lane wrote:
>
> >
> >
> >With a little more intelligence in the manager of this table, this could
> >also solve my concern about pointer variables.  Perhaps the entries
> >could include not just address/size but some type information.  If the
> >manager knows "this variable is a pointer to a palloc'd string" then it
> >could do the Right Thing during fork.  Not sure offhand what the
> >categories would need to be, but we could derive those if anyone has
> >cataloged the variables that get passed down from postmaster to children.
> >
> >I don't think it needs to be a hashtable --- you wouldn't ever be doing
> >lookups in it, would you?  Just a simple list of things-to-copy ought to
> >do fine.
> >
> >

> I'm thinking in a threaded context where a method may need to lookup a
> global that is not passed in.  But for copying, I suppose no lookups
> would be neccessary.

if we can, can we keep the whole 'threaded' concept in mind when
developing this ... if going a hashtable would be required for this, let's
go the more complete route and eliminate potential issues down the road
...





pgsql-hackers by date:

Previous
From: "Rod Taylor"
Date:
Subject: Array iterators
Next
From: "Marc G. Fournier"
Date:
Subject: Re: 7.2.2 ?