Thread

PG+Cygwin Production Experience (was RE: Path to PostgreSQL porta biliy)

Henshall, Stuart - WCP <shenshall@westcountrypublications.co.uk> — 2002-05-09T09:46:03Z

Ooops sorry about the last post (all thumbs today)

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 08 May 2002 16:57
> To: Thomas Lockhart
> Cc: mlw; PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann
> Corbit
> Subject: Re: Path to PostgreSQL portabiliy 
> 
> 
> Thomas Lockhart <lockhart@fourpalms.org> writes:
> > 2) If (1) does not exempt the PostgreSQL app from GPL 
> polution, then why
> > not distribute PostgreSQL on Windows using a GPL license?
> 
> Given the cygwin licensing terms stated at
> 	http://cygwin.com/licensing.html
> it appears to me that we need not open that can of worms (and I'd much
> rather not muddy the licensing waters that way, regardless of any
> arguments about whether it would hurt or not...)

Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )
I have heard it said that an ipc implementation will be appearing in the
main
cygwin DLL, but have yet to see it.

> 
> As near as I can tell, we *could* develop a self-contained 
> installation
> package for PG+cygwin without any licensing problem.  So that set of
> problems could be solved with a reasonable amount of work.  I'm still
> unclear on whether there are serious technical problems (performance,
> stability) with using cygwin.
> 
> (Actually, even if there are performance or stability problems, an
> easily-installable package would still address the needs of people who
> want to "try it out" or "get their feet wet".  And maybe that's all we
> need to do.  We always have said that we recommend a Unix platform for
> production-grade PG installations, and IMNSHO that 
> recommendation would
> not change one iota if there were a native rather than cygwin-based
> Windows port.  So I'm unconvinced that we have a problem to solve
> anyway...)
> 
> 			regards, tom lane
> 

The system has about 30 transactional users on average.
Why am I using NT? IT has decided it is the way.
The major limitation on performance appears to be fork() as this actually
copies the memory, rather than just copy on write. Also I believe it has fix
up some of the file descriptors for things like sockets, and those things
that
have no fd under windows, but do under *nix. This seems to be the only major
performance bottle neck, although I havn't done much comparison testing.
Other limitations are:
Processes - Can only have 62 Children due to WaitForMultipleObjects 64 item
	limit. (I'm wondering about tackling this, however it'll be my first
	forey into cygwin so don't hold your breath)
Memory - Starts at 256Mb limit, can be increased by a registry key:
	//HKCU/Software/Cygnus Solutions/Cygwin/
		heap_chunk_in_mb			DWORD
As can be seen, this uses Current User so you need to make sure your
ipc-daemon service starts as the correct user as well as the postmaster.
If you use a lot of shared memory, the opstmaster can take a while to start,
but this isn't a problem for me.

As to stability, don't use on Win9x. This is just about usable for
development
but it keeps crashin at ramdom times, especially when restoring from dump
files.
I have never managed to complete make installcheck on 9x.
Sometimes things seem to be broken in a new version of cygwin, to be fixed
by
the next. Just need to test before using. Also I only use plpgsql for server
side programing. I know there are problems building for TCL, and I don't
know
about perl and python.
The only other problems I've had with NT4 are:
a) When running as a service, it wouldn't term in time due to sighup. Fixed
b) As of 7.2.1 (don't know about 7.2, not tried it enough), the following
causes a problem when restoring large amounts of data, which is solved by
just using rename (see previous postings to pgsql-cgywin)
	/*
	 * Prefer link() to rename() here just to be really sure that we
don't
	 * overwrite an existing logfile.  However, there shouldn't be one,
so
	 * rename() is an acceptable substitute except for the truly
paranoid.
	 */
#ifndef __BEOS__
	if (link(tmppath, path) < 0)
		elog(STOP, "link from %s to %s (initialization of log file
%u, segment %u) failed: %m",
			 tmppath, path, log, seg);
	unlink(tmppath);
#else
	if (rename(tmppath, path) < 0)
		elog(STOP, "rename from %s to %s (initialization of log file
%u, segment %u) failed: %m",
			 tmppath, path, log, seg);
#endif

Hope something here helps the discussion,
- Stuart

P.S. I will not be on email Fri-Mon (inclusive), but if anyone wants further
	info/discussion on particulars, I will be available from Tuesday 
	(or some of today).