I must say that cygwin did well (there exists good software on windows,
i've found one)... as a prototype ... when I look at the postgresql poll
(http://www.postgresql.org/survey.php?View=1&SurveyID=11), it seems like
I'm not alone !!
Actually, the major problem was the limit of the available allocable
memory restricted by cygwin.
We don't plan to wait for the 7.5 win native version of postgresql. It was
hard enough to decide moving to linux, I don't want to rollback
Thanks for the advice, I will definetely have a look at the new version
anyway as soon as it is released.
Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
Pour : bsimon(at)loxane(dot)com
cc : pgsql-performance(at)postgresql(dot)org
Objet : Re: Réf. : Re: [PERFORM] NAS, SAN or any alternate solution ?
> As we don't plan to have more than 5 connections (I.E process), we
> think SATA drives would fit our requirements. Could this be an issue
> for an after crash recovery ?
If you can disable the write ATA write cache, then you have safety.
Unfortunately many cards under Linux show up as SCSI devices, and you
can't access this setting. Does anyone know if the newer SATA cards let
you control this?
You might want to keep and eye on the upcoming native windows port in
7.5 - It will come with a fearsome array of caveats... but you have been
running cygwin in production! - and I am inclined to think the native
port will be more solid than this configuration.
pgsql-performance by date
|Next:||From: abhousehunt||Date: 2004-07-20 10:45:07|
|Subject: Re: Working on huge RAM based datasets|
|Previous:||From: Mark Kirkwood||Date: 2004-07-20 10:04:28|
|Subject: Re: Réf. : Re: [PERFORM] NAS,|