SEO

#1 (**permalink**) 04-17-2008, 11:00 PM

Dave Page wrote:

>When starting as a service at boot time on Windows, pg_autovacuum may
>fail to start because the PostgreSQL service is still starting up. This
>patch causes the service to attempt a second connection 30 seconds after
>the initial connection failure before giving up entirely.
>
>

In the windows service world, is there any reason pg_autovacuum should
ever give up? The reason I had it give up was so that it didn't
accidently run against a different postgresql instance. I don't think
that will happen in the windows service world. I think it should keep
trying to do it's job until it's told to exit.

Matthew

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

#2 (**permalink**) 04-17-2008, 11:00 PM

"Matthew T. O'Connor" <matthew@zeut.net> writes:
> In the windows service world, is there any reason pg_autovacuum should
> ever give up?

I was a bit worried about the scenario in which J Random Luser tries to
start the server twice and ends up with two autovacuum daemons attached
to the same postmaster. I'm not sure if this is possible, probable,
or dangerous ... but it seems like a point to consider.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

#3 (**permalink**) 04-17-2008, 11:00 PM

Tom Lane wrote:

>"Matthew T. O'Connor" <matthew@zeut.net> writes:
>
>
>>In the windows service world, is there any reason pg_autovacuum should
>>ever give up?
>>
>>
>
>I was a bit worried about the scenario in which J Random Luser tries to
>start the server twice and ends up with two autovacuum daemons attached
>to the same postmaster. I'm not sure if this is possible, probable,
>or dangerous ... but it seems like a point to consider.
>

It is a good point to consider. Let me be a little more detailed in my
explanation and see if that helps:
* A never give up pg_autovacuum would only be used when run as a windows
service.
* The windows service control manager can still kill pg_autovacuum, so
you shouldn't be able to start more than one that way.
* You have always been able to run multiple pg_autovacuums, it's not
advisable, and it's only bad side effect would be excessive, or more
than expected, vacuum commands.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

#4 (**permalink**) 04-17-2008, 11:00 PM

"Matthew T. O'Connor" <matthew@zeut.net> writes:
> Tom Lane wrote:
>> I was a bit worried about the scenario in which J Random Luser tries to
>> start the server twice and ends up with two autovacuum daemons attached
>> to the same postmaster. I'm not sure if this is possible, probable,
>> or dangerous ... but it seems like a point to consider.

> It is a good point to consider. Let me be a little more detailed in my
> explanation and see if that helps:
> * A never give up pg_autovacuum would only be used when run as a windows
> service.
> * The windows service control manager can still kill pg_autovacuum, so
> you shouldn't be able to start more than one that way.
> * You have always been able to run multiple pg_autovacuums, it's not
> advisable, and it's only bad side effect would be excessive, or more
> than expected, vacuum commands.

OK, that seems to take care of my worries above.

I agree with the point someone else made that if the service keeps trying
to start forever, it wouldn't be obvious to the user that it wasn't
working. So a limited time window seems best ... but I think it needs
to be at least five minutes.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: pg_autovacuum Win32 Service startup delay