Обсуждение:

On 7/22/2014 11:14 PM, Kalai R wrote:

Well the above would indicate it is not being shutdown properly.

How are you shutting it down?

PSQL server starterd as stoped by postgresql windows service. So when I shutdown the machine postgres shutting down by postgres windows service

What and how are you installing?

Using windows binary zip file, I extract zip file and create cluster using intidb then register windows service using pg_ctl

Who are you running the service as?

I try to start the psql server from command prompt using pg_ctl.exe

why not use the installer, which sets it all up correctly for you?

I think the problem is, you ran initdb as your user account, but the system service is running as the special system accounbt NETWORK_SERVICE, or similar, and there may be files in the data directory which the NETWORK_SERVICE account doesn't have write access writes to.   you can probably fix this with the cacls command.

-- 
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On 7/22/2014 11:42 PM, Kalai R wrote:

why not use the installer, which sets it all up correctly for you?

In previous, I use installer. but I face more data corruption problem and also server starting problem  when shutting down the system.  so I try to install my self. 

I think the problem is, you ran initdb as your user account, but the system service is running as the special system accounbt NETWORK_SERVICE, or similar, and there may be files in the data directory which the NETWORK_SERVICE account doesn't have write access writes to.   you can probably fix this with the cacls command.

I think you are correct. But I want to know why database corrupted even though I shutting down the machine properly. This is frequently happen when I use installer also.

It seems like Windows isn't waiting for the service to exit cleanly before its pulling the plug.   Is this a Windows *server* version, or is it one of the newer desktop OS's like Windows 8?   Windows 8 seems to shut down rather fast, its quite possible its not bothering to wait for services to exit.

this error...

FATAL:  could not remove symbolic link "pg_tblspc/17681": Permission denied

CONTEXT:  xlog redo create tablespace: 17681 "C:/GLOIER/gPRO/Data/GT"

suggests you're using a postgres tablespace ?  I've not used tablespaces much or at all in Windows, I don't know how well they work.

-- 
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On 07/22/2014 11:59 PM, Kalai R wrote:

* Is this a Windows *server* version, or is it one of the newer desktop

OS's like Windows 8?   Windows 8 seems to shut down rather fast, its

quite possible its not bothering to wait for services to exit.*
*

*
I face  this problem in Windows XP and Windows 7 but not all windows XP
and Windows 7.
In Windows 8 and Windows Server no problem.

*
*
*It seems like Windows isn't waiting for the service to exit cleanly
before its pulling the plug.**
*
*

*
I think so, but I don't know how to solve this problem.

First would be to show the log entries from the period immediately before the server shutdown incorrectly.

From the previous go around on this:

http://www.postgresql.org/message-id/CAGxuanNsgNDTCv1bm+ap2tSr=vztGca_yvAFrXwW=9W0o3MOPw@mail.gmail.com

you indicated that you application does things when installing itself and the server.

It would be nice to know what that is?

In particular an outline of the exact steps you application takes during the install.

--
Adrian Klaver
adrian.klaver@aklaver.com

On 23 July 2014 22:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Krystian Bigaj <krystian.bigaj@gmail.com> writes:
> - when pg_console_handler receives CTRL_SHUTDOWN_EVENT from OS, then it
> calls pg_queue_signal(SIGINT).

> Problems:
> - when OS is in shutdown path, then it sends CTRL_SHUTDOWN_EVENT, and *all*
> Postgres processes (main and sub/forked) will call pg_queue_signal(SIGINT)
> - so main and sub processes will start to shutdown independently? Can this
> have any bad consequences?

Hm.  We ought to have that sending SIGTERM instead, so as to mimic the
situation when Unix "init" is trying to shut down the system.  It might be
that SIGINT will more or less work, but the postmaster logic is designed
to work with global SIGTERM as being the clean-up-ASAP trigger.  As an
example, backends servicing remote applications (which will *not* have
already gotten killed) would not exit in response to SIGINT.

> I think that CTRL_SHUTDOWN_EVENT should be removed from pg_console_handler,

That does not sound like a good idea, at least not if Windows has the
same behavior as "init" does of proceeding to hard kills after some
grace period.

                        regards, tom lane

I'm not really familiar with Unix and it's SIG-commands. I know only about SIGINT/SIGTERM from Postgres documentation.

However form what I see is that when Postgress is running by pg_ctl from service, then it will receive SIGINT (independently and in general in unspecified order)

- *each* postgres.exe process will queue itself SIGINT (because of CTRL_SHUTDOWN_EVENT),

- pg_ctl will send SIGINT to main postmaster process (and possibly it will pass that command to sub-processes)

So there are two independent paths where SIGINT are sent, and pg_ctl doesn't have really a control when postgres.exe receives SIGINT.

This CTRL_SHUTDOWN_EVENT is not used when postgres.exe is run on *user session* - so removing it won't change anything.

I see only two cases where CTRL_SHUTDOWN_EVENT might be need (all of there where postgres.exe is run on service session):

- postgres.exe run by pg_ctl.exe, but pg_ctl service process was terminated/killed, and then system was shutdown

- someone starts postgres.exe from own service, but doesn't send SIGINT/SIGTERM command to postgres.exe on service system shutdown (but he must for service stop)

As I previously wrote, I have workaround for it, so if you think that this change would break compatibility and don't want to change it, then I'm really fine with it.

However I've probably found something with pg_ctl.c regarding shutdown and maybe that suspicious postgres.exe process termination on Windows.

1) shutdownEvent is signaled in pgwin32_ServiceMain by SERVICE_CONTROL_STOP/SERVICE_CONTROL_SHUTDOWN in pgwin32_ServiceHandler

There is dwWaitHint = 10000.

2)

...

  /* Wait for quit... */

ret = WaitForMultipleObjects(2, shutdownHandles, FALSE, INFINITE);

pgwin32_SetServiceStatus(SERVICE_STOP_PENDING); 

switch (ret)

{

case WAIT_OBJECT_0: /* shutdown event */

kill(postmasterPID, SIGINT);

/*

* Increment the checkpoint and try again Abort after 12

* checkpoints as the postmaster has probably hung

*/

while (WaitForSingleObject(postmasterProcess, 5000) == WAIT_TIMEOUT && status.dwCheckPoint < 12)

status.dwCheckPoint++; <---- missing call to pgwin32_SetServiceStatus(SERVICE_STOP_PENDING) or SetServiceStatus(hStatus, (LPSERVICE_STATUS) &status);

break;

...

There is incremented dwCheckPoint every 5000ms, but that status is not updated (missing pgwin32_SetServiceStatus/SetServiceStatus), so SCM after 10s (dwWaitHint = 10000) will not receive incremented dwCheckPoint, and it's allowed to kill that process (because this service didn't respond with dwWaitHint). It kills pg_ctl.exe, but when all services stops, then it simply terminates other remaining processes - in this case postgres.exe

http://msdn.microsoft.com/en-us/library/windows/desktop/ms685996(v=vs.85).aspx

dwWaitHint:

...

If the amount of time specified by dwWaitHint passes, and dwCheckPoint has not been incremented or dwCurrentState has not changed, the service control manager or service control program can assume that an error has occurred and the service should be stopped.

...

So if main postgres.exe (run by pg_ctl.exe service process) won't shutdown in 10s (for any reason) it might be terminated/killed by Windows/SCM.

Best regards,
Krystian Bigaj