Thread: Re: [pgsql-www] NuSphere and PostgreSQL for windows
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
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
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
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
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
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
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
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
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
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
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.
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