Re: Porting to Native WindowsNT/2000

"Ken Hirsch" <kenhirsch(at)myself(dot)com> writes:

> > (To be honest, the idea of worrying about security vulnerabilities on
> > Windows seems odd to me. If you are honestly worried about security
> > on your database server, the first step is to stop running Windows.)
>
> That's just a cheap shot. I've seen no evidence that Windows NT/2000 is
> inherently less secure than any given Unix or Linux distribution, it is just
> a lot more popular and tends to have less experienced system administrators.

I agree that it looks like a cheap shot, but I didn't intend to make
one. There are various arguments why Windows NT is probably less
secure than Unix, ranging from interface design to code maturity to
platform popularity to actual statistics of numbers of cracked systems
and numbers of different successful cracks. I personally don't know
of any arguments why Unix is less secure than Windows NT, other than
guessing. Unless you are an expert in the field, which I am not, I
think you should follow the preponderance of evidence, which I read as
saying that where security is a significant concern, it's best to
avoid Windows. (This is off-topic for the Postgres mailing list,
though, so if I reply on this further I'll take it off list.)

> Having an easy-to-install Windows set up would be a plus for Postgres.
> There are millions of Windows NT servers out there.

I agree.

> > > Two.... could Postgres be made more efficient on Windows if it ran
> > > without cygwin?
> >
> > Yes. Cygwin adds measurable overhead to all I/O operations, and
> > obviously a database does a lot of I/O. Postgres employs operations
> > which are fast on Unix but are very slow on cygwin, such as fork.
> >
> > As mlw said, porting Postgres to run natively on Windows would be a
> > significant effort. The forking mechanism it uses currently would
> > have to be completely rearchitected.
>
> This is true. However, a process-pool architecture would benefit Postgres
> on other platforms besides Windows. Postgresql has been ported to the
> HP3000 MPE/iX operating system, for example, which is POSIX-compliant, but
> has an awfully slow fork().

On the other hand, POSIX-compliant systems generally are moving toward
a faster and faster fork, as they should given the nature of POSIX
programs.

A process pool architecture for a system like Postgres would require
very careful attention to memory usage, in order to be able to return
swap space to the system or at least avoid using it. Otherwise, I
believe the different processes would fragment memory over time,
decreasing system performance. Process pools work best for systems
with fixed memory usage.

> > The buffer, file manager, and
> > networking code would have to be rewritten.
>
> I don't think this is true. Most of the unix-style interfaces are
> supported out of the box by the Microsoft C compiler.

I've written code which ran natively on both Unix and Windows, and
that kind of statement doesn't get you very far. Even when the
interfaces are the same, there are critical differences all over the
place (e.g., select() on Windows only works on sockets, not pipes).
You can deal with each problem as it comes up, but they keep coming
up. That's why Steve Chamberlain started the cygwin project in the
first place--we were both at Cygnus at the time, and I spent several
months working on cygwin myself a couple of years later.

Ian