public inbox for [email protected]  

help / color / mirror / Atom feed

From: Shridhar Daithankar <[email protected]>
To: Tom Lane <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: [email protected]
Subject: Re: [pgsql-www] NuSphere and PostgreSQL for windows
Date: Thu, 25 Sep 2003 19:12:39 +0530
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<1064492591.25702.2084.camel@camel>
	<[email protected]>

Tom Lane wrote:

> Robert Treat <[email protected]> writes:
> 
>>On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
>>
>>>SRA's Windows port is up to 7.3.4, and I think they just released
>>>version 1.1, so that is going fine --- and I have the source code to
>>>use in our native Win32 port, just not the threading stuff.
> 
> 
>>And if I've paid attention, the threading bits are what SRA used to get
>>around the fork/exec issues?  
> 
> 
> BTW, I've been wondering lately if we'd not be better off to look at
> using threading in the Windows port, if it'd help us get around the
> fork/exec data transfer problem.  I'm not sure that it would, mind you,
> but if it would give an answer it might be a lot less painful than
> solving the data transfer problem directly.
> 
> Our main objections to threading in the past have always been lack of
> portability and loss of robustness.  Portability isn't an issue for a
> Windows-only solution, and I'm not too concerned about the other either,
> since I'll never think that Windows would be a place to run a production
> server anyway.

Assuming windows port would be built out of same code tree as that of unix 
builds....

Considering this could be a configure time option, you mean to say that even on 
Unix we could get threaded postgresql which would not require any shared buffers 
but instead operate upon local shared buffers only?

Of course that would remain an option only. Old behaviour of process/shared 
memory will still be there..

Do I understand this correctly? If abstraction work is going to be done, adding 
thread-model specific could be just another layer.

So we have..

- Windows thread model
- pthreads on unix model
- Process+shared buffers model

And postgresql could work in either of the modes depending upon platform.

That would be good news. I am sure local buffers would be lot cheaper than 
shared buffers.

  Shridhar

view thread (25+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [pgsql-www] NuSphere and PostgreSQL for windows
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox