Re: 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(at)mail(dot)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(at)postgresql(dot)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(at)mail(dot)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(at)mail(dot)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(at)mail(dot)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.