Home
The Toolkit for Online Communities
17103 Community Members, 2 members online, 2193 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : PostgreSQL Reliability on Windows 2000

Forum OpenACS Q&A: PostgreSQL Reliability on Windows 2000

Icon of envelope Request notifications

Collapse
Posted by Matthew Soldo on
Does anyone have any experience with the reliability of PostgreSQL
on Windows 2000? For political reasons we can't use Linux :-( But we
definitely need our platform to be rock solid. It will be doing
nothing but run the database, but will need to be able to handle
about 8 inserts/second and 5 queries/second (its a decently powerful
machine, 1ghz/1gb ram/scsi).

Thanks

Collapse
Posted by Jonathan Ellis on
I run PG under cygwin on win2k with zero problems but it's pretty much a "toy" database -- just tracks our perforce cuts and does simple queries on that data.

I would guess that your performance requirements are on the high end of doable but that's just a guess.  If you had problems it would almost certainly be with the inserts.

Collapse
Posted by Roberto Mello on
AFAIK it's as reliable as Windows 2000 is, if that says anything. You lose some performance, but things on Win2K are pretty slow anyways, so nothing to worry about. Keep your PG VACCUM'd and and backed up and things go swell.
Collapse
Posted by russell muetzelfeldt on
We've had a look at deploying on 2K for one particular client. We
got OACS and the custom app we've developed for them up and
running, but postgresql was never stable enough to deploy -
whenever we tried to import the data from their old system PG
would start dying with shared memory errors. Adding a .25
second delay between record insertions let us get the system
fully loaded, but we'd see the same database crashes whenever
we stressed the system.

Personally, I'd be very wary of running PG under production loads
on windows, but perhaps that's just me...

Collapse
Posted by Roberto Mello on
Did you try incresing the shared buffer size for PostgreSQL?
Collapse
Posted by russell muetzelfeldt on
The errors weren't postgres complaining about not having
enough memory, but that the shared memory segments had
been corrupted. We did try (among other things) increasing
shared_buffers, which didn't as far as I recall make any
difference.

I wonder if we were perhaps hitting some limit in cyg_ipc wrt the
amount of shared memory it can support... hmm...

Collapse
Posted by Don Baccus on
Shared memory corruption sounds a lot like an issue with locking, which makes me suspicious that perhaps Cygwin hasn't quite gotten their implementation right?
Collapse
Posted by Andrei Popov on
You can use it, but I would not recommend putting a production system on it.  OTOH, if for politacal reasons you must use W2K, I am a bit surprized that you can use PostgreSQL :)

Besides (assuming you want to use OACS as well), you'd be facing at least 2 more problems with W2K/PostgreSQL/AOLServer: (a) support issue (as you know, AOL folks no longer support Windows version of AOLServer); (b) some functionality on AOLServer side would be missing and/or not working well.

For example of a (b), I could never get binary file uploads to work well on Windows/AOLServer combination (but that was about a year back with OACS 3.2.5 and on NT).

Collapse
Posted by Jamie Rasmussen on
Russell - do you remember what version of PostgreSQL you were using? There were shared memory errors across many platforms. http://archives.postgresql.org/pgsql-general/1998-08/msg00183.php Many of these bugs have been fixed in the later versions.

I do think that cygipc (http://www.neuro.gatech.edu/users/cwilson/cygutils/index.html) is the weakest link in the chain right now. It will get rolled into the forthcoming "Cygwin Daemon" but is currently deprecated by the author.

If you end up doing any benchmarking, I would love to see the results! My PostgreSQL 7.1.3/Cygwin OpenACS site is not experiencing 8 inserts/second, but it would be great if it could. :-)

Collapse
Posted by Jamie Rasmussen on
An update on AOLserver on Win32 - the AOLserver 4 beta sources have been changing rapidly. I've brought most of the trivial changes over to my source tree. I'm investigating the more substantial differences, like whether or not a switch to pthreads (http://sources.redhat.com/pthreads-win32/) is a good idea. I've got an MSI installer ready to go when the sources settle down. BTW, is anyone testing the AOLserver betas with OpenACS on Linux? I have a few questions...

I'm not sure I completely grasp Matthew's situation - can you say what the political reasons are? Is MacOS X a possibility? How are you going to be connecting to PostgreSQL? Is this for an OpenACS installation?

Collapse
Posted by Yon Derek on
Jamie, I'm surprised that you (or anyone else) can use Aolserver 4 with OpenACS 4.x. Last time I checked (granted, that was long time ago) a support for extended ADP parser (that, I believe, ArsDigita added to AOLServer 3.x) has been removed (alng with the possibility to register new parsers via modules). This ADP parser is needed by OpenACS 4.x templating system. I've managed to replace AOlserver 4 ADP parser with a ported 3.x parser but that was a bit ugly.

Did the support for extended parser has been restored in AOLServer 4 since (i.e. is anyone able to run OpenACS 4.x on unmodified AOLServer 4)?

Collapse
Posted by russell muetzelfeldt on
Jamie - This was late last year, on 7.1.3... certainly well beyond
the 6.3.x that was current in late '98...
Collapse
Posted by Jamie Rasmussen on
Yon - The code I am currently running is from last November, with the patches you supplied on Sourceforge earlier that year. (#434722, #440568) All but one of the acs-templating demos work. There are certainly still some issues - the <multiple> tag in default-master.adp doesn't work because it is inside the <body> tag for example.

In late December, the adp parser was rewritten to minimize duplicate overhead of per-thread bytecode caches. In the past few days it has had a few more changes. Registered tags can now be modified after startup. There are some new commands like ns_adp_safeeval, which blocks open <% ... %> scripting. I haven't tried out this newer code with OpenACS yet, but I don't think it will cause problems.