Thread: Re: [pgsql-www] NuSphere and PostgreSQL for windows

Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Tom Lane
Date:
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.

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.
        regards, tom lane


Re: NuSphere and PostgreSQL for windows

From
Andreas Pflug
Date:
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




Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Shridhar Daithankar
Date:
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.
> 
> 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




Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Andrew Dunstan
Date:
Tom Lane wrote:

>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.
>

I am sure you are correct. The whole Windows API is more multi-thread 
friendly than multi-process friendly, and operates far more efficiently 
that way, as I understand it. There is also some potential benefit on 
some *nix systems, where thread creation is far less costly than 
forking, or at least this used to be the case last time I looked at it.

>
>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.
>
>  
>
Not that I like Windows all that much, but using it for a server is 
becoming more defensible as an option. As for portability, what *nix is 
there these days that doesn't have some sort of lightweight thread support?

Maybe the relevant parts of the system need to be abstracted out and 
threading generally made a build time option (on by default for Windows, 
off by default otherwise, maybe?)

cheers

andrew



Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Tom Lane
Date:
Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> 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?

Only if we were prepared to support multiple, no doubt incompatible
threading libraries, which is exactly what I wasn't volunteering us for.

> I am sure local buffers would be lot cheaper than shared buffers.

On what do you base that?  It sounds like pure fantasy to me.  RAM is RAM.
        regards, tom lane


Re: NuSphere and PostgreSQL for windows

From
Tom Lane
Date:
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Tom Lane wrote:
>> 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.

> 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.

Yeah, it would reverse the problem from "how to share data" to "how not
to share data".  We'd want to find a way to ensure that the bulk of the
static data becomes per-thread data (or, in some cases, add a mutex so
that multiple threads can safely share one copy).  It won't be a trivial
bit of work, but conceivably it could be less messy than trying to store
and reload many of those same variables.
        regards, tom lane


Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Shridhar Daithankar
Date:
Tom Lane wrote:

> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> 
>>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?
> 
> 
> Only if we were prepared to support multiple, no doubt incompatible
> threading libraries, which is exactly what I wasn't volunteering us for.

In my view, we have a advantage here. If we say that we would support a 
reasonable pthreads implementation, that would be good enough, because we have a 
working product in process model.

So we can let that platform catchup with threading model at it's own pace.  Till 
that time it can work in older model. We need not push really hard for platform 
incompatible threading models like say mysql have to do.

The little pthreads programming I did on linux/freeBSD tells me that it supports 
majority of features except TLS(linux2.4/linuxthreads) and per thread signals. 
IIRC HP-UX supports pthreads as well and recommends moving to that threading 
model. Solaris surely does support pthreads.

>>I am sure local buffers would be lot cheaper than shared buffers.
> On what do you base that?  It sounds like pure fantasy to me.  RAM is RAM.

For sure that is correct. But kernel interaction would matter. e.g. a linux 
kernel without pre-emption/low latency and one with all those features would 
certainly register speed and latency differences for heavily contended buffers. 
The issue will be even more grave for small amount of buffers since they will be 
contended more.

Its not about RAM. Its about how lightweight and/or efficient kernel 
implementaion of shared memory and cross-process synchronisation object is. 
Surely say linux and solaris are going to register differences..:-)
 Shridhar



Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Greg Stark
Date:
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> > 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?
> 
> Only if we were prepared to support multiple, no doubt incompatible
> threading libraries, which is exactly what I wasn't volunteering us for.

Well if you're only going to do one threading API you may as well pick the
POSIX standard. Windows threading is only useful for windows, POSIX threading
would work on every other OS, Solaris, Linux, BSD, etc.

Is there a POSIX threads wrapper for windows?

-- 
greg



Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Greg Stark
Date:
Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:

> The little pthreads programming I did on linux/freeBSD tells me that it
> supports majority of features except TLS(linux2.4/linuxthreads) and per thread
> signals. 

LinuxThreads is dead. NPTL is the way and the light.

It has ELF TLS which for super-fast thread-local storage, proper per-thread
signal semantics, as well as not using USR1,USR2 in ways that mess up
signal-handling. It also has kernel support for user-space mutexes (strange as
that may sound).

> >>I am sure local buffers would be lot cheaper than shared buffers.
> > On what do you base that?  It sounds like pure fantasy to me.  RAM is RAM.

Well that's not entirely true. Thread context switches don't involve MMU
operations the way process context switches do. So even though RAM is RAM, the
RAM in the threaded implementation might be faster to access simply because
it's already in the processor cache. The process model has to do a TLB flush
and load a whole new page table which takes a lot of time to begin with, and
then slows down all memory accesses later.

-- 
greg



Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Andreas Pflug
Date:
Andrew Dunstan wrote:

> Tom Lane wrote:
>
>> 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.
>>
>
> I am sure you are correct. The whole Windows API is more multi-thread 
> friendly than multi-process friendly, and operates far more 
> efficiently that way, as I understand it. There is also some potential 
> benefit on some *nix systems, where thread creation is far less costly 
> than forking, or at least this used to be the case last time I looked 
> at it.
>
>>
>> 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.
>>
>>  
>>
> Not that I like Windows all that much, but using it for a server is 
> becoming more defensible as an option. As for portability, what *nix 
> is there these days that doesn't have some sort of lightweight thread 
> support?
>
> Maybe the relevant parts of the system need to be abstracted out and 
> threading generally made a build time option (on by default for 
> Windows, off by default otherwise, maybe?) 

This seems to be the best option.
Whether a specific *ix application really benefits from threads or 
suffers from this, should be evaluated on each platform. Having this 
option is certainly advantageous.

BTW, this would lower the problems with memory over-commit: no forking, 
no spare mem allocation needed, right?

Regards,
Andreas



Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Philip Yarra
Date:
On Fri, 26 Sep 2003 01:18 am, Greg Stark wrote:
> Well if you're only going to do one threading API you may as well pick the
> POSIX standard. Windows threading is only useful for windows, POSIX
> threading would work on every other OS, Solaris, Linux, BSD, etc.
>
> Is there a POSIX threads wrapper for windows?

Yes and no... there's no native POSIX thread wrapper, if that's what you mean
(say like pthreads on OSF wraps DECThreads AFAIK).

There's a  development effort here (http://sources.redhat.com/pthreads-win32/)
to help those using Windows, but if it was me, I'd probably stick to native
Windows threads. It's not going to be on people's machines by default.

Regards, Philip.



Re: [pgsql-www] NuSphere and PostgreSQL for windows

From
Shridhar Daithankar
Date:
Greg Stark wrote:

> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> 
> 
>>The little pthreads programming I did on linux/freeBSD tells me that it
>>supports majority of features except TLS(linux2.4/linuxthreads) and per thread
>>signals. 
> 
> 
> LinuxThreads is dead. NPTL is the way and the light.
> 
> It has ELF TLS which for super-fast thread-local storage, proper per-thread
> signal semantics, as well as not using USR1,USR2 in ways that mess up
> signal-handling. It also has kernel support for user-space mutexes (strange as
> that may sound).

Well.. Linuxthreads or NPTL, they are going to conform to pthreads standard 
right? In fact NPTL is supposed to be better conformant than linuxthreads.
 Shridhar