Thread: postgresql 8.0 on windows 2003 server
Hello everyone. Thanks for the answers earlier about the new 8.0 version. We have a client who is thinking about putting postgresql 8.0 on Windows 2003 Server, but he is concerned because this is the first version to run natively on windows. Are there any issues with 8.0 on Windows? Also, with Linux it was possible to improve performance by increasing the amount of shared memory in /etc/shmmax (http://www.phpbuilder.com/columns/smith20010821.php3). Does this need to be done in Windows? Thanks! Si Chen
On Fri, Feb 25, 2005 at 15:12:07 -0800, Si Chen <schen@graciousstyle.com> wrote: > Hello everyone. Thanks for the answers earlier about the new 8.0 version. > > We have a client who is thinking about putting postgresql 8.0 on Windows > 2003 Server, but he is concerned because this is the first version to > run natively on windows. Are there any issues with 8.0 on Windows? I think the windows problems have been pretty minimal. To get an idea of the scope, you might take a look at the 8.0.1 release notes.
>Hello everyone. Thanks for the answers earlier about the new >8.0 version. > >We have a client who is thinking about putting postgresql 8.0 >on Windows >2003 Server, but he is concerned because this is the first version to >run natively on windows. Are there any issues with 8.0 on Windows? There are a couple of smaller issues. The biggest one is probably that the stats collector fails under load. This does not endanger your data in any way, but you can't use that functionality. There are also some know performance issues in write-intensive apps taht are being worked on. Some issues with localisation of error messages are also known. There are sure to be other minor things as well, as it is the first version. But there are several fairly large installations up and running without issues that I know of, so it's not *that* bad. >Also, with Linux it was possible to improve performance by increasing >the amount of shared memory in /etc/shmmax >(http://www.phpbuilder.com/columns/smith20010821.php3). Does >this need >to be done in Windows? No. You can increase shared_buffers in postgresql.conf, but there is no need to change the system configuration (otehr than possibly enlarging your pagefile if you run out). Wether the "sweet spot" for shared_buffers is similar in win32 and unix is one of the things that lacks data at the moment, so you'll just have to experiment around for your specific workload. //Magnus
On Fri, 2005-02-25 at 17:12, Si Chen wrote: > Hello everyone. Thanks for the answers earlier about the new 8.0 version. > > We have a client who is thinking about putting postgresql 8.0 on Windows > 2003 Server, but he is concerned because this is the first version to > run natively on windows. Are there any issues with 8.0 on Windows? There was a report of the stats monitor dying under heavy load just the other day. And the lack of testing in a heavy load environment would keep me from putting the two in the data center together just now, but it's certainly good enough for workgroup / internal use. > Also, with Linux it was possible to improve performance by increasing > the amount of shared memory in /etc/shmmax > (http://www.phpbuilder.com/columns/smith20010821.php3). Does this need > to be done in Windows? I do not know. I'd imagine giving PostgreSQL a bit of extra memory for shared buffers would help. I don't know if you'd have to reconfigure any part of windows to make it possible, or just change the setting in postgresql.conf
Bruno Wolff III <bruno@wolff.to> writes:
> Si Chen <schen@graciousstyle.com> wrote:
>> Are there any issues with 8.0 on Windows?
> I think the windows problems have been pretty minimal. To get an idea
> of the scope, you might take a look at the 8.0.1 release notes.
The problems we've *fixed* have been pretty minimal ;-) ... but those
release notes don't tell you about open issues.
Offhand I recall that there are some serious performance problems
associated with fsync behavior, and some people report instability
of the statistics collector for reasons unknown.
regards, tom lane