Message-ID: <3F72F033.30903@pse-consulting.de>
Date: Thu, 25 Sep 2003 15:40:03 +0200
From: Andreas Pflug <pgadmin@pse-consulting.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
	pgsql-hackers@postgreSQL.org
Subject: Re: NuSphere and PostgreSQL for windows
References: <200309241711.h8OHBMi20283@candle.pha.pa.us>
	<1064492591.25702.2084.camel@camel> <1794.1064494772@sss.pgh.pa.us>
In-Reply-To: <1794.1064494772@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

>Robert Treat <xzilla@users.sourceforge.net> 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.
>
When talking about threading in pgsql to Bruce on Linuxtag, he stated 
that the main problem would be the tons of global variables used 
throughout the backend. Killing global variables might give more 
flexibility and coding robustness.

>Our main objections to threading in the past have always been lack of
>portability and loss of robustness.
>
MS SQL seems to have a mechanism that lets it kill faulty threads 
without bringing down the whole process, however that works (I've seen 
several crashes on a single connection, while the server process 
continued to work). So the current advantage of dedicated backend 
processes might be preservable with threading.

>  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.
>
This sounds *very* naive. I'm quite sure that a lot of admins will use 
the win32 pgsql for production use, because their corporation 
infrastructure says "we run M$ servers", and thus only develepment and 
testing machines have Linux running.

The win32 port is demanded and expected to give a boost to pgsql usage, 
probably not caused by test machines only...

Regards,
Andreas