Обсуждение: Windows Services and Postgresql 9.1.3

Hi,
I'm using Postgresql 9.1.3 x64 on Windows 2008,
I'm doing reliability tests and effects and consequences of a server power failure.

What I see is that when Windows reboots from a power failure sometimes the Windows postgresql service is not in sync with the actual state of postgres.

For example, after the server had rebooted, I would stop the service from services.msc
Windows then reports it as stopped but I can still see that the database is running,  and can use it.
When I would start the service again, I would end up with a timeout waiting for the service to be started. When in fact the database was always running.

Anyone had that bug/problem before ?

Thank You,
Vincent.



 

On 09/12/2012 04:48 AM, Vincent Dautremont wrote:

> For example, after the server had rebooted, I would stop the service
> from services.msc
> Windows then reports it as stopped but I can still see that the database
> is running,  and can use it.

Check in the process monitor (or, better, with Process Explorer from
Sysinternals) to see what user the `postgres.exe` processes are running as.

> When I would start the service again, I would end up with a timeout
> waiting for the service to be started. When in fact the database was
> always running.
>
> Anyone had that bug/problem before ?

Nope. Sounds completely crazy. More info needed, though.

--
Craig Ringer

Yes, is a Bug, sometimes in some circumstances pg_ctl go down but postgres
server still running.

You can easily reproduce.

Go to "task manager", kill the process "pg_ctl" (simulate some kind of crash
or something else).
Now go to services management and try to start again. Start command will
through an error because pg_ctl can't start database because is already
started.

Due to this bug I always use the pg_ctl command directly and not the windows
service.

Running pg_ctl command from command prompt show that postgres server is
running, but windows service show stopped and is not possible to start again
from windows service UI

Maybe a resolution of this is that pg_ctl ignore the start call from windows
(just success it) when it is already running.

Regards

-----Mensaje original-----
De: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] En nombre de Craig Ringer
Enviado el: lunes, 17 de septiembre de 2012 12:43 a.m.
Para: Vincent Dautremont
CC: pgsql-admin@postgresql.org
Asunto: Re: [ADMIN] Windows Services and Postgresql 9.1.3

On 09/12/2012 04:48 AM, Vincent Dautremont wrote:

> For example, after the server had rebooted, I would stop the service
> from services.msc Windows then reports it as stopped but I can still
> see that the database is running,  and can use it.

Check in the process monitor (or, better, with Process Explorer from
Sysinternals) to see what user the `postgres.exe` processes are running as.

> When I would start the service again, I would end up with a timeout
> waiting for the service to be started. When in fact the database was
> always running.
>
> Anyone had that bug/problem before ?

Nope. Sounds completely crazy. More info needed, though.

--
Craig Ringer


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

BTW, the windows service also can remain in an inconsistent state when the
pg_ctl can't stop the postgres server.
I think that pg_ctl uses stop "fast" so, if for some reason postgres don't
response to stop fast, the service in windows service UI appear as stopping
for long time and finally after some kind of timeout it show as not started.

Obviously, if it appear as not started you want to start, but you can't. And
maybe some inexperienced user get crazy, "database is stopped and can't
start" but really DB is started.

What the inexperienced do is the only thing he can do... Restart the server,
when he restart the postgres server receive a KILL message and then
everything get worse


I live this situation time ago and obviously learn :)


-----Mensaje original-----
De: Anibal David Acosta [mailto:aa@devshock.com]
Enviado el: lunes, 17 de septiembre de 2012 09:27 p.m.
Para: 'Craig Ringer'; 'Vincent Dautremont'
CC: 'pgsql-admin@postgresql.org'
Asunto: RE: [ADMIN] Windows Services and Postgresql 9.1.3

Yes, is a Bug, sometimes in some circumstances pg_ctl go down but postgres
server still running.

You can easily reproduce.

Go to "task manager", kill the process "pg_ctl" (simulate some kind of crash
or something else).
Now go to services management and try to start again. Start command will
through an error because pg_ctl can't start database because is already
started.

Due to this bug I always use the pg_ctl command directly and not the windows
service.

Running pg_ctl command from command prompt show that postgres server is
running, but windows service show stopped and is not possible to start again
from windows service UI

Maybe a resolution of this is that pg_ctl ignore the start call from windows
(just success it) when it is already running.

Regards

-----Mensaje original-----
De: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] En nombre de Craig Ringer Enviado
el: lunes, 17 de septiembre de 2012 12:43 a.m.
Para: Vincent Dautremont
CC: pgsql-admin@postgresql.org
Asunto: Re: [ADMIN] Windows Services and Postgresql 9.1.3

On 09/12/2012 04:48 AM, Vincent Dautremont wrote:

> For example, after the server had rebooted, I would stop the service
> from services.msc Windows then reports it as stopped but I can still
> see that the database is running,  and can use it.

Check in the process monitor (or, better, with Process Explorer from
Sysinternals) to see what user the `postgres.exe` processes are running as.

> When I would start the service again, I would end up with a timeout
> waiting for the service to be started. When in fact the database was
> always running.
>
> Anyone had that bug/problem before ?

Nope. Sounds completely crazy. More info needed, though.

--
Craig Ringer


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Tue, Sep 11, 2012 at 2:48 PM, Vincent Dautremont
<vincent@searidgetech.com> wrote:
> Hi,
> I'm using Postgresql 9.1.3 x64 on Windows 2008,
> I'm doing reliability tests and effects and consequences of a server power
> failure.

If you're looking to test for reliability and bugginess, I'd highly
suggest testing against the latest minor version of 9.1.5.

On Fri, 21 Sep 2012 10:33:25 -0600, Scott Marlowe wrote:

> On Tue, Sep 11, 2012 at 2:48 PM, Vincent Dautremont
> <vincent@searidgetech.com> wrote:
>> Hi,
>> I'm using Postgresql 9.1.3 x64 on Windows 2008,
>> I'm doing reliability tests and effects and consequences of a server
>> power failure.
>
> If you're looking to test for reliability and bugginess, I'd highly
> suggest testing against the latest minor version of 9.1.5.

If reliability of interest, why is OP using Windows?

On 09/22/2012 06:25 AM, Walter Hurry wrote:
> On Fri, 21 Sep 2012 10:33:25 -0600, Scott Marlowe wrote:
>
>> On Tue, Sep 11, 2012 at 2:48 PM, Vincent Dautremont
>> <vincent@searidgetech.com> wrote:
>>> Hi,
>>> I'm using Postgresql 9.1.3 x64 on Windows 2008,
>>> I'm doing reliability tests and effects and consequences of a server
>>> power failure.
>>
>> If you're looking to test for reliability and bugginess, I'd highly
>> suggest testing against the latest minor version of 9.1.5.
>
> If reliability of interest, why is OP using Windows?

FWIW, my Win2k8 server has been rock solid since installation, with only
*extremely* infrequent reboots for patches as few of the issues patched
are network-exploitable.

These days Windows is a rather solid platform. It still weirds me out,
but that's how it is. I've had more stability issues on my Linux servers
lately (though that's significantly to do with some of the cheap and
nasty hardware they're on).

--
Craig Ringer

Guys,
Thank you for the info about this.
(we are using windows, as we don't have high loads usage of the database and we use then the same server to run our server applications).

Vincent.