Обсуждение: 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