> -----Original Message-----
> From: Thomas Lockhart [mailto:thomas@fourpalms.org]
> Sent: Wednesday, June 05, 2002 3:03 PM
> To: Bruce Momjian
> Cc: Igor Kovalenko; PostgreSQL-development
> Subject: Re: [HACKERS] Roadmap for a Win32 port
> 
> 
> ...
> > Good summary.  I think we would support both threaded and fork()
> > operation, and users can control which they prefer.  For a 
> web backend
> > where many sessions are a single query, people may want to 
> give up the
> > stability of fork() and go with threads, even on Unix.
> 
> I would think that we would build on our strengths of having 
> a fork/exec
> model for separate clients. A threaded model *could* benefit 
> individual
> clients who are doing queries on multiprocessor servers, and 
> I would be
> supportive of efforts to enable that.
> 
> But the requirements for that may be less severe than for managing
> multiple clients within the same process, and imho there is not strong
> requirement to enable the latter for our current crop of well 
> supported
> targets. If it came for free then great, but if it came with 
> a high cost
> then the choice is not as obvious. It is also not a 
> *requirement* if we
> were instead able to do the multiple threads for a single client
> scenerio first.

Notion:
Have one version do both.  Your server can fork(), and your sever can
thread.  It can fork() and thread, it can fork() or thread.

That gives the best of all worlds.  One client who has his attachments
to a database all setup might want to do a bunch of similar queries.
Hence a threaded model is nice.

A server may be set up to clone the rights of the attaching process for
security reasons.  Then you launch a new server with fork().

Wed, 5 Jun 2002 15:09:29 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Roadmap for a Win32 port
...
> Notion:
> Have one version do both.  Your server can fork(), and your sever can
> thread.  It can fork() and thread, it can fork() or thread.
> That gives the best of all worlds.  One client who has his attachments
> to a database all setup might want to do a bunch of similar queries.
> Hence a threaded model is nice.
> A server may be set up to clone the rights of the attaching process for
> security reasons.  Then you launch a new server with fork().

Right. If/when that is possible then let's do it, as long as the cost is
not too high. But the intermediate steps are a possibility also, and are
not precluded from discussion.

This will all work out as a *convergence* of interests imho. And there
is no great identifiable benefit for our current crop of platforms for
going to a threaded model *unless* that enables queries for a single
client to execute in parallel (all imho of course ;). 

So our convergence of interests for all platforms is in enabling
threading for these two purposes, and focusing on enabling the
multithreaded single client *first* means that the current crop of
clients don't have to accept all negatives while we start on the road to
better support of Win32 machines.

                  - Thomas

Wed, 05 Jun 2002 15:21:22 -0700
Thomas Lockhart <thomas@fourpalms.org>
Re: Roadmap for a Win32 port