Thread: Windows installation service
The Windows installation service uses pg_ctl to perform the network start-up operation. This program starts up the postmaster and exits. The net effect of performing the operation in this manner is that the Windows service manager sees the service as "not running" a few minutes after the startup is complete. It also prevents proper pause and restart of the service. As a suggestion: Instead of installing pg_ctl as the service, start up postgres as the service. This is how we did our Windows port. If the idea is appealing to the PostgreSQL group, we can send our service code modifications for review as a possible alternative to the current method. Another approach that could be equally helpful (along the same lines) is to leave pg_ctl.exe in memory and allow it to control the program.
On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit <DCorbit@connx.com> wrote: > The Windows installation service uses pg_ctl to perform the network > start-up operation. > This program starts up the postmaster and exits. > The net effect of performing the operation in this manner is that the > Windows service manager sees the service as "not running" a few minutes > after the startup is complete. It also prevents proper pause and > restart of the service. Per our offlist conversation, this is not how it works. > As a suggestion: > Instead of installing pg_ctl as the service, start up postgres as the > service. This is how we did our Windows port. If the idea is appealing > to the PostgreSQL group, we can send our service code modifications for > review as a possible alternative to the current method. > > Another approach that could be equally helpful (along the same lines) is > to leave pg_ctl.exe in memory and allow it to control the program. Which is what does happen. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dann Corbit wrote: > The Windows installation service uses pg_ctl to perform the network > start-up operation. > This program starts up the postmaster and exits. > The net effect of performing the operation in this manner is that the > Windows service manager sees the service as "not running" a few minutes > after the startup is complete. I don't know what platform you're running on, but this isn't true of either of the machines I am looking at right now (one Vista, one WS2k3), which (correctly) show the service as started. cheers andrew
> -----Original Message----- > From: Dave Page [mailto:dpage@pgadmin.org] > Sent: Friday, April 10, 2009 8:16 AM > To: Dann Corbit > Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee; > Brian Fifer > Subject: Re: [HACKERS] Windows installation service > > On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit <DCorbit@connx.com> wrote: > > The Windows installation service uses pg_ctl to perform the network > > start-up operation. > > This program starts up the postmaster and exits. > > The net effect of performing the operation in this manner is that the > > Windows service manager sees the service as "not running" a few > minutes > > after the startup is complete. It also prevents proper pause and > > restart of the service. > > Per our offlist conversation, this is not how it works. > > > As a suggestion: > > Instead of installing pg_ctl as the service, start up postgres as the > > service. This is how we did our Windows port. If the idea is > appealing > > to the PostgreSQL group, we can send our service code modifications > for > > review as a possible alternative to the current method. > > > > Another approach that could be equally helpful (along the same lines) > is > > to leave pg_ctl.exe in memory and allow it to control the program. > > Which is what does happen. I don't know the reason why, but that is not what happens here. We see the problem on 64-bit machines with Windows 2008 Server. We see the problem on 32-bit machine with Windows 2003 Server. We see the problem on 32-bit Windows XP machines. It is universal (all of these machines demonstrate the problem). I did get this email from Mike McKee this morning: "I noticed a pattern. The first time it works, and can shutdown. The second time is where it kind of hangs ...."
> -----Original Message----- > From: Dann Corbit > Sent: Friday, April 10, 2009 12:30 PM > To: 'Dave Page' > Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee; > Brian Fifer > Subject: RE: [HACKERS] Windows installation service > > > -----Original Message----- > > From: Dave Page [mailto:dpage@pgadmin.org] > > Sent: Friday, April 10, 2009 8:16 AM > > To: Dann Corbit > > Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike > McKee; > > Brian Fifer > > Subject: Re: [HACKERS] Windows installation service > > > > On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit <DCorbit@connx.com> > wrote: > > > The Windows installation service uses pg_ctl to perform the network > > > start-up operation. > > > This program starts up the postmaster and exits. > > > The net effect of performing the operation in this manner is that > the > > > Windows service manager sees the service as "not running" a few > > minutes > > > after the startup is complete. It also prevents proper pause and > > > restart of the service. > > > > Per our offlist conversation, this is not how it works. > > > > > As a suggestion: > > > Instead of installing pg_ctl as the service, start up postgres as > the > > > service. This is how we did our Windows port. If the idea is > > appealing > > > to the PostgreSQL group, we can send our service code modifications > > for > > > review as a possible alternative to the current method. > > > > > > Another approach that could be equally helpful (along the same > lines) > > is > > > to leave pg_ctl.exe in memory and allow it to control the program. > > > > Which is what does happen. > > I don't know the reason why, but that is not what happens here. > > We see the problem on 64-bit machines with Windows 2008 Server. > We see the problem on 32-bit machine with Windows 2003 Server. > We see the problem on 32-bit Windows XP machines. > It is universal (all of these machines demonstrate the problem). > > I did get this email from Mike McKee this morning: > > "I noticed a pattern. > > The first time it works, and can shutdown. > > The second time is where it kind of hangs ...." I should mention that PostgreSQL is still operational. The Postgres servers are in memory and I am able to perform queries,despite the apparent status of the service.
On Fri, Apr 10, 2009 at 8:29 PM, Dann Corbit <DCorbit@connx.com> wrote: > I don't know the reason why, but that is not what happens here. > > We see the problem on 64-bit machines with Windows 2008 Server. > We see the problem on 32-bit machine with Windows 2003 Server. > We see the problem on 32-bit Windows XP machines. > It is universal (all of these machines demonstrate the problem). > > I did get this email from Mike McKee this morning: > > "I noticed a pattern. > > The first time it works, and can shutdown. > > The second time is where it kind of hangs ...." So what is unusual about your machines that makes this happen for you, but apparently noone else we've heard of? Are you running on a domain? Any nonstandard security policy or other configuration? I know Connx have experience developing on Windows, so can one of you attach a debugger and see why the WaitForMultipleObjects() call in pg_ctl doesn't work on your systems? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
> -----Original Message----- > From: Dave Page [mailto:dpage@pgadmin.org] > Sent: Friday, April 10, 2009 1:58 PM > To: Dann Corbit > Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee; > Brian Fifer > Subject: Re: [HACKERS] Windows installation service > > On Fri, Apr 10, 2009 at 8:29 PM, Dann Corbit <DCorbit@connx.com> wrote: > > > I don't know the reason why, but that is not what happens here. > > > > We see the problem on 64-bit machines with Windows 2008 Server. > > We see the problem on 32-bit machine with Windows 2003 Server. > > We see the problem on 32-bit Windows XP machines. > > It is universal (all of these machines demonstrate the problem). > > > > I did get this email from Mike McKee this morning: > > > > "I noticed a pattern. > > > > The first time it works, and can shutdown. > > > > The second time is where it kind of hangs ...." > > So what is unusual about your machines that makes this happen for you, > but apparently noone else we've heard of? Are you running on a domain? Yes. This is a corporation, so we don't run peer to peer. > Any nonstandard security policy or other configuration? Nothing unusual. > I know Connx have experience developing on Windows, so can one of you > attach a debugger and see why the WaitForMultipleObjects() call in > pg_ctl doesn't work on your systems? Here is what we tried: We decided to start the service from the command line as an executable rather than a service. First, we found permissions problems: C:\CONNX32\CONNXSTORE\bin>C:\CONNX32\CONNXSTORE\bin\pg_ctl.exe start -w -N "pgsql-8.3" -D "C:\CONNX32\CONNXSTORE\data\" waiting for server to start...2009-04-10 14:55:22 PDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2009-04-10 14:55:22 PDT PANIC: could not open control file "global/pg_control": Permission denied This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ............................................................could not start server We allowed user postgres to have full control for the global folder. C:\CONNX32\CONNXSTORE\bin>C:\CONNX32\CONNXSTORE\bin\pg_ctl.exe start -w -N "pgsql-8.3" -D "C:\CONNX32\CONNXSTORE\data\" waiting for server to start...2009-04-10 15:09:50 PDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2009-04-10 15:09:50 PDT LOG: could not create file "postmaster.opts": Permission denied ................... done server started We had a similar problem with the data folder, so we changed permissions for user postgres to have full control for the data folder. C:\CONNX32\CONNXSTORE\bin>C:\CONNX32\CONNXSTORE\bin\pg_ctl.exe start -w -N "pgsql-8.3" -D "C:\CONNX32\CONNXSTORE\data\" waiting for server to start...2009-04-10 15:19:49 PDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" ............................................................could not start server After those changes, we no longer had permissions problems but the server did not start from the command line. I uninstalled Postgresql I removed the postgres user I removed the postgres directory structure I installed PostgreSQL postgresql-8.3.7-1. Apparently this version does not have the same bad symptoms (I have not checked all the other machines yet -- that will take some time).
Hi, I'm having 'service' issues too: Windows XP SP3 user account used for service is not a member of admin group. Errors starting service, but dbengine is started and available. If i try to stop/start with the pgctl batch files created during install, same type of problem... PC had 8.2-5.1 installed originally, I upgraded it to 8.3-6 (without stopping or removing the 8.2 service) I have since removed the 8.2 installation and deleted the 8.2 folder from Program Files, and also have changed the environment variables (that aren't updated automatically.....) I think I can 'fix' by removing completely and reinstalling fresh, but i'd like to know how to not have to do this... -- View this message in context: http://www.nabble.com/Windows-installation-service-tp22989478p23522185.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.