Обсуждение: pgAgent Windows service startup time
Hello, The first time I tried to setup the pgAgent job scheduler on Windows I was wondered the service couldn't start for a very long time. Further investigation shown that the 'poll time interval' executable parameter (-t) affects startup time. Moreover, startup time directly reflects this parameter. At first, I set (-t 600) meaning I want the pgAgent poll my server ones every 10 minutes. Having sent the 'start' control to the service I had at last to kill the process, because it was remaining in the 'Starting' state for several minutes. But leaving the '-t' parameter to default (10 seconds) caused the service to start exactly in 10 seconds! And so on. I doubt it's a feature; what if I want to poll a PostgreSQL server every day? pgAgent will be starting during a whole day? Both PostgreSQL and pgAgent services are running on Windows Server 2003 Standard Edition SP2. PostgreSQL 8.3.7 pgAgent 3.0.0 (as of Mar 2009) Regards, Dmitry.
On Thu, Sep 17, 2009 at 8:03 AM, Dmitry Samokhin <sdld@mail.ru> wrote: > Hello, > > The first time I tried to setup the pgAgent job scheduler on Windows I was > wondered the service couldn't start for a very long time. Further > investigation shown that the 'poll time interval' executable parameter (-t) > affects startup time. Moreover, startup time directly reflects this > parameter. At first, I set (-t 600) meaning I want the pgAgent poll my > server ones every 10 minutes. Having sent the 'start' control to the service > I had at last to kill the process, because it was remaining in the > 'Starting' state for several minutes. But leaving the '-t' parameter to > default (10 seconds) caused the service to start exactly in 10 seconds! And > so on. > I doubt it's a feature; what if I want to poll a PostgreSQL server every > day? pgAgent will be starting during a whole day? I'll assume you've realised that setting the poll time to 600 means that jobs will run up to 10 minutes late? Regardless of that, you are correct that this behaviour is undesirable. Please try the replacement binary at http://uploads.enterprisedb.com/download.php?file=624b234667456b2208548393c6a03ae3. I'll commit the fix to SVN for the next release. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
> I'll assume you've realised that setting the poll time to 600 means > that jobs will run up to 10 minutes late? > > Regardless of that, you are correct that this behaviour is > undesirable. Please try the replacement binary at > http://uploads.enterprisedb.com/download.php?file=624b234667456b2208548393c6a03ae3. > I'll commit the fix to SVN for the next release. I tried this new binary, and upon start both Windows XP and Server 2003 report "The system cannot execute the specified program". Is it built for Windows? Dmitry. > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com > > -- > Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-support >
On Thu, Sep 17, 2009 at 2:57 PM, Dmitry Samokhin <sdld@mail.ru> wrote: >> I'll assume you've realised that setting the poll time to 600 means >> that jobs will run up to 10 minutes late? >> >> Regardless of that, you are correct that this behaviour is >> undesirable. Please try the replacement binary at >> http://uploads.enterprisedb.com/download.php?file=624b234667456b2208548393c6a03ae3. >> I'll commit the fix to SVN for the next release. > > I tried this new binary, and upon start both Windows XP and Server 2003 > report "The system cannot execute the specified program". Is it built for > Windows? Yes, but maybe you don't have the right runtimes installed on your machine. Does the original build work on that box? Where did you get that from? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
>> I tried this new binary, and upon start both Windows XP and Server 2003 >> report "The system cannot execute the specified program". Is it built for >> Windows? > > Yes, but maybe you don't have the right runtimes installed on your > machine. Does the original build work on that box? Where did you get > that from? The original build was downloaded from the official website: http://wwwmaster.postgresql.org/download/mirrors-ftp/pgadmin3/release/pgagent/pgAgent-3.0.0-win32.zip. It works OK without any problem except I started this thread on. All runtime libs are from the official PostgreSQL 8.3.7 distribution. Maybe this test binary now requires any additional runtimes? Or maybe the file got corrupted when uploaded/downloaded? I downloaded it two times, file size is 376832 bytes. Please check this and re-upload if needed. Seems that something wrong with the executable itself, since when I attempt to start the release binary and it cannot find the libs an error window is displayed with the message like this: "This application has failed to start because LIBPQ.dll was not found. Re-installing the application may fix this problem". Dmitry.
> Yes, but maybe you don't have the right runtimes installed on your
> machine. Does the original build work on that box? Where did you get
> that from?
Here is some additional info, which may help to localize the problem. What
reports the message "The system cannot execute the specified program" is the
Windows command shell ('cmd'). Starting this binary by the Windows Explorer
I get "This application has failed to start because the application
configuration is incorrect" (and the same message is placed into the Event
log when the application is started as a service). I have found some info in
the Internet:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/36971526-95f3-4a9f-a601-1843c86332c1.
The corresponding VC++ redistributables seem to be already installed on my
machine. To ensure it, I run the package directly:
http://www.microsoft.com/downloads/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en.
Unfortunately that not helps. What should I check else? Your build
environment changed since pgAgent v3.0.0?
Dmitry.
begin 666 trans.gif?cver=2.4.1184.0
K1TE&.#EA`0`!`( ``/___P```"'Y! $`````+ `````!``$```("1 $`.P``
`
end
On Fri, Sep 18, 2009 at 9:22 AM, Dmitry Samokhin <sdld@mail.ru> wrote: > Unfortunately that not helps. What should I check else? Your build > environment changed since pgAgent v3.0.0? Nope, no changes. Here's the full package - maybe it did get corrupted: http://uploads.enterprisedb.com/download.php?file=168611b64d377f857f4cd86cb9fb6d12 -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
> Nope, no changes. Really it seems there are :)) Exploring the embedded manifests in the both executables I found an additional dependency in the new one: <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> </dependentAssembly> It relates to the Security update for Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package: http://support.microsoft.com/?kbid=973544 and can be downloaded from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2 Please note this preparing the release. After installing this package we experience no problem, the service always starts in just one second. Generally, it's perfectly clear that we can get job execution delay up to the poll interval time. A proposed improvement for the pgAgent that might be taken into account in the future is to store last read schedules (relative to the server's real time) locally. And then to connect to the server when the time is about to come for the nearest next job to execute regardless of the poll interval set. Thanks for your help. Dmitry.
On Fri, Sep 18, 2009 at 1:55 PM, Dmitry Samokhin <sdld@mail.ru> wrote: >> Nope, no changes. > > Really it seems there are :)) Exploring the embedded manifests in the both > executables I found an additional dependency in the new one: > > <dependentAssembly> > <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" > version="8.0.50727.4053" processorArchitecture="x86" > publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> > </dependentAssembly> > > It relates to the Security update for Microsoft Visual C++ 2005 Service Pack > 1 Redistributable Package: > http://support.microsoft.com/?kbid=973544 Oh, that's annoying. Well spotted. > and can be downloaded from > http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2 > > Please note this preparing the release. > > After installing this package we experience no problem, the service always > starts in just one second. > Generally, it's perfectly clear that we can get job execution delay up to > the poll interval time. A proposed improvement for the pgAgent that might be > taken into account in the future is to store last read schedules (relative > to the server's real time) locally. And then to connect to the server when > the time is about to come for the nearest next job to execute regardless of > the poll interval set. Not sure that's such a good idea. What happens if your next job is scheduled for next month, and you add one for next week? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
>> Generally, it's perfectly clear that we can get job execution delay up to >> the poll interval time. A proposed improvement for the pgAgent that might >> be >> taken into account in the future is to store last read schedules >> (relative >> to the server's real time) locally. And then to connect to the server >> when >> the time is about to come for the nearest next job to execute regardless >> of >> the poll interval set. >Not sure that's such a good idea. What happens if your next job is >scheduled for next month, and you add one for next week? My little fault in explanation, 'regardless of the poll interval set' means to poll next time not later anyway than when the current interval (by the '-t' setting) ends, but maybe earlier (according to the locally stored schedules). Dmitry.