Обсуждение: Installing Postgres 8.1 on Windows Server 2003 R2

> Has anyone tried to install Postgres on Windows Sever 2003
> version R2?  R2 is actually shipping as a 'new' Microsoft
> product- it's basically an interim update to Windows Server (
> http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.msp
> x <http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.mspx> ).

Not that I know of, but it's been on my list of things to try :-)


> I've installed Postgres on other versions of Windows with no
> problem, so I'm afraid that the error I'm seeing now is
> related to some great new 'feature' from Microsoft.  Here's
> the error message returned by Postgres before install begins-
> Error binding the test network socket: 10013

That error means: An attempt was made to access a socket in a way
forbidden by its access permissions.

> Microsoft Antispyware has been turned off (closed the
> application) and Windows Firewall isn't running.  There's no
> other AV or firewall software on this system yet.
>
> Any ideas on what might be going on?

It certainly *sounds* a lot like a firewall issue :-) I'd double and
triple check that. We've seen it several times before and it has AFAIK
always been a firewall.


//Magnus

Carl Conard wrote:
> I've successfully installed Postgres 8.1.2 on WS 2003 R2 on a Lenovo
> (IBM) ThinkPad.  I used the default installation options and everything
> seems peachy keen for a single user (using localhost).
>
> However, when we started performance testing Postgres (vs. MySQL) using
> a 3rd party tool (I forget the name) running on the server, Postgres
> would drop connections after about the 10th or 11th virtual user (of 20)
> hit the DB.  The remaining user processes would remain visible in
> Window's Task Manager and just "hang."

How are you connecting?
What do you mean by "drop connections"?
What do you mean by "hang" - does the server have problems shutting them
down if you tell it to?
What do the logs show?
What changes have you made to your configuration files?

--
   Richard Huxton
   Archonet Ltd

Connections are through localhost.  We've also connected via a client
machine through a router to insure it is not something on the server.

By drop connections, I mean Task Manager is showing additional
postgres.exe tasks after the completion of the test.  Also, when we try
to drop the DB to reset for another test, PGAdmin reports connections.
Finally, of the 20 virtual users, any where from 2 to 12 or so will
successfully complete the test (by adding information to the DB via our
PHP app).

The postmaster can be shut down manually with no issues after the test.
However, upon rebooting the machine, I get IIS Helper Failed messages.
I don't know if this is related or not.

Logs don't really show anything.  At least nothing I can find.

The only changes to the config file was to enable the logging at verbose
and info levels.  I can send the file if you'd like to see it.

I've noticed a number of issues about beta releases dealing with sockets
and such.  I haven't found anything indicating they were fixed or if
there are work arounds.

-----Original Message-----
From: Richard Huxton [mailto:dev@archonet.com]
Sent: Tuesday, January 24, 2006 3:09 AM
To: Carl Conard
Cc: Postgres User; Magnus Hagander; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Installing Postgres 8.1 on Windows Server 2003 R2

Carl Conard wrote:
> I've successfully installed Postgres 8.1.2 on WS 2003 R2 on a Lenovo
> (IBM) ThinkPad.  I used the default installation options and
everything
> seems peachy keen for a single user (using localhost).
>
> However, when we started performance testing Postgres (vs. MySQL)
using
> a 3rd party tool (I forget the name) running on the server, Postgres
> would drop connections after about the 10th or 11th virtual user (of
20)
> hit the DB.  The remaining user processes would remain visible in
> Window's Task Manager and just "hang."

How are you connecting?
What do you mean by "drop connections"?
What do you mean by "hang" - does the server have problems shutting them

down if you tell it to?
What do the logs show?
What changes have you made to your configuration files?

--
   Richard Huxton
   Archonet Ltd

Carl Conard wrote:
> Connections are through localhost.  We've also connected via a client
> machine through a router to insure it is not something on the server.

No, I meant what client library: odbc, jdbc .net libpq?

> By drop connections, I mean Task Manager is showing additional
> postgres.exe tasks after the completion of the test.  Also, when we try
> to drop the DB to reset for another test, PGAdmin reports connections.

Are you certain the application is disconnecting properly?

> Finally, of the 20 virtual users, any where from 2 to 12 or so will
> successfully complete the test (by adding information to the DB via our
> PHP app).
>
> The postmaster can be shut down manually with no issues after the test.
> However, upon rebooting the machine, I get IIS Helper Failed messages.
> I don't know if this is related or not.

OK, so you're connecting from PHP running on IIS by the sound of it.

> Logs don't really show anything.  At least nothing I can find.

Are they showing connections and disconnects? If not, check you've
turned this on in your postgresql.conf

> The only changes to the config file was to enable the logging at verbose
> and info levels.  I can send the file if you'd like to see it.

All you should need at the moment is connection logging and perhaps
statement logging (to see what queries get executed).

> I've noticed a number of issues about beta releases dealing with sockets
> and such.  I haven't found anything indicating they were fixed or if
> there are work arounds.

It wouldn't be released if connections failed randomly. There have been
issues with network performance on Win2K machines, but that seems to be
sorted once the QoS add-on gets installed.

I think what you need is something like:
1. A copy of the PostgreSQL logs showing each connection/disconnect.
2. A log from your application code showing where it
connects/disconnects and the result codes it gets for each.
3. A count of how many connections are still present at the end of your
test.

This should fairly quickly show where the problem is. If it doesn't then
we'll need to either:
1. turn on statement logging too to see if there is a pattern.
2. Reduce the application to just connect/disconnect and see if the
probem persists.

My guess as to the source of this problem would be:
1. Application error - some code-path where a disconnect doesn't
actually happen. Because PG listens over an IP socket on Windows it'll
sit there until the connection times out.
2. Some issue with IIS/PHP running threaded and the connection library not.
--
   Richard Huxton
   Archonet Ltd