Subject: NuSphere and PostgreSQL for windows

From: Oleg Bartunov <[email-masked]>
Date: Fri, 19 Sep 2003 14:51:49 +0400 (MSD)

Hi there,

I got message from nusphere.com about windows port of PostgreSQL.
They're looking for full time developer in Russia,Moscow.

Is this is a joke ?

	Regards,
		Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [email-masked], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---

From: "Marc G. Fournier" <[email-masked]>
Date: Fri, 19 Sep 2003 10:06:23 -0300 (ADT)

On Fri, 19 Sep 2003, Robert Treat wrote:

> From the folks who brought you lawsuits with mysql... If it is true it
> is the first I have heard of it. While I don't see why it couldn't be
> true (as nusphere did market a mysql database at one time) it seems a
> little odd since this would be pretty direct competition with their
> parent company, Progress Software. The other odd part being that they
> are looking for a developer in Moscow, I didn't know they had offices in
> Russia and I don't see mention of any on thier website.

Ummmm ... wasn't Peer Direct a child company of Progress?  NuSphere was
their MySQL "division", and Peer Direct was their "PostgreSQL"?
Basically, put both hands in the pie and hope one comes out with some
fruit?

---

From: Oleg Bartunov <[email-masked]>
Date: Fri, 19 Sep 2003 17:58:20 +0400 (MSD)

Robert,

On Fri, 19 Sep 2003, Robert Treat wrote:

> Oleg, depending on the confidentially level of the letter (given that
> some core members work for would be direct competitors), could you
> forward it to this list or perhaps some of us directly? I'm sure
> Josh/myself would like to take a look, it could have interesting
> ramifications from an advocacy point-of-view.

there is nothing to add, except the company was mentioned as
NuSphere (PeerDirect) and From: field was nusphere.com. It's interesting
that the message was sent to me and Teodor Sigaev. I recall,
a year ago I got message from one russian developer about something like
GiST for MySQL. He is the author of UdmSearch (MnogoSearch).

>
> Robert Treat
>
> On Fri, 2003-09-19 at 06:51, Oleg Bartunov wrote:
> > Hi there,
> >

	Regards,
		Oleg

---

From: Tom Lane <[email-masked]>
Date: Fri, 19 Sep 2003 11:25:16 -0400

> Is this is a joke ?

No, I expect they're serious.  NuSphere does still own the PeerDirect
windows port that Jan worked on at his former job.  They need someone
to maintain that and bring it forward to newer versions of PG.  It's
not going to be a long-term product (assuming that we ever finish the
community's native port), so they need to keep the costs down.  I'm
not surprised that they'd be looking to send the development overseas
instead of keeping it at their US offices.

			regards, tom lane

---

From: Oleg Bartunov <[email-masked]>
Date: Fri, 19 Sep 2003 20:31:45 +0400 (MSD)

> instead of keeping it at their US offices.

Hmm, I suspect they have some developers here in Russia. At least full text
search resembles me MnogoSearch. Anyway, I'm not willing to work with them.
Postgres forever

>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

	Regards,
		Oleg

---

From: Robert Treat <[email-masked]>
Date: 19 Sep 2003 17:26:54 -0400

> search resembles me MnogoSearch. Anyway, I'm not willing to work with them.

Don't be too hasty. I don't know about anyone else, but I'd welcome an
updated commercial native windows solution (When's SRA's port coming out
in 1.0?) , especially if they'd be willing to provide a "diff" of the
code back to the community. We might as well have someone get paid for
work we will probably have to do anyways...  

Robert Treat   
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---

From: "Marc G. Fournier" <[email-masked]>
Date: Fri, 19 Sep 2003 22:36:08 -0300 (ADT)

> work we will probably have to do anyways...

I think a few things that Oleg needs to find out first is whether or not
PeerDirect *will* feed it back to the community ... how much did they feed
back of Jan's work?  Considering where win32 seems to be sitting, it
doesn't seem like much ...

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 24 Sep 2003 13:09:09 -0400 (EDT)

> GiST for MySQL. He is the author of UdmSearch (MnogoSearch).

I can confirm that Nusphere still has a division in Russia, and they
need PostgreSQL assistance, perhaps for the replication part of
PeerDirect.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email-masked]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 24 Sep 2003 13:10:39 -0400 (EDT)

> work we will probably have to do anyways...  

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.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 24 Sep 2003 13:11:22 -0400 (EDT)

> doesn't seem like much ...

PeerDirect contributed the code, but neither they or Jan wanted to port
it up to current CVS, and that's were we/I got stuck.

---

From: Robert Treat <[email-masked]>
Date: 25 Sep 2003 08:23:11 -0400

> it up to current CVS, and that's were we/I got stuck.

So it would be a boon for them to pay someone to bring it up to date
(assuming they would donate it back to the community).

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

Incidentally I don't recall any announcements from SRA that they were
past the beta development phase with their version, seems like that
could have gotten some mention on the main postgresql site. 

Robert Treat

---

From: Tom Lane <[email-masked]>
Date: Thu, 25 Sep 2003 08:59:32 -0400

> 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

---

From: Andreas Pflug <[email-masked]>
Date: Thu, 25 Sep 2003 15:40:03 +0200

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

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

---

From: Shridhar Daithankar <[email-masked]>
Date: Thu, 25 Sep 2003 19:12:39 +0530

> since I'll never think that Windows would be a place to run a production

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

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 25 Sep 2003 09:58:31 -0400

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

>since I'll never think that Windows would be a place to run a production
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

---

From: Tom Lane <[email-masked]>
Date: Thu, 25 Sep 2003 10:01:50 -0400

Shridhar Daithankar <[email-masked]> 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

---

From: Tom Lane <[email-masked]>
Date: Thu, 25 Sep 2003 10:07:39 -0400

Andreas Pflug <[email-masked]> writes:
>> fork/exec data transfer problem.

> 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

---

From: Shridhar Daithankar <[email-masked]>
Date: Thu, 25 Sep 2003 19:44:50 +0530

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

> 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

---

From: Greg Stark <[email-masked]>
Date: 25 Sep 2003 11:18:51 -0400

> 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

---

From: Greg Stark <[email-masked]>
Date: 25 Sep 2003 11:53:10 -0400

Shridhar Daithankar <[email-masked]> 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).

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

---

From: Andreas Pflug <[email-masked]>
Date: Thu, 25 Sep 2003 19:08:54 +0200

Andrew Dunstan wrote:

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

---

From: Philip Yarra <[email-masked]>
Date: Fri, 26 Sep 2003 10:20:06 +1000

On Fri, 26 Sep 2003 01:18 am, Greg Stark wrote:
> POSIX standard. Windows threading is only useful for windows, POSIX
> threading would work on every other OS, Solaris, Linux, BSD, etc.
>

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.

---

From: Shridhar Daithankar <[email-masked]>
Date: Fri, 26 Sep 2003 12:07:12 +0530

> signal-handling. It also has kernel support for user-space mutexes (strange as

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

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 9 Oct 2003 13:57:02 -0400 (EDT)

> could have gotten some mention on the main postgresql site. 

Here is SRA's News page, translated into English:

	http://www.excite.co.jp/world/url/body/?wb_url=http%3A%2F%2Fosb.sra.co.jp&submit=%83E%83F%83u%83y%81%5B%83W%96%7C%96%F3&wb_lp=JAEN&wb_dis=2&wb_co=excitejapan

(Babelfish has problems, so I used Excite.)  You can see the products
they have.  I will post something to the PostgreSQL events list.