Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-27 Thread Dave Page
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 24 January 2005 23:58 > To: Dave Page > Cc: pgsql-patches@postgresql.org > Subject: Re: [PATCHES] pg_autovacuum Win32 Service startup delay > > "Dave Page" writes: > > Wh

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-25 Thread Tom Lane
"Matthew T. O'Connor" 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 s

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-25 Thread Matthew T. O'Connor
Tom Lane wrote: "Matthew T. O'Connor" 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 po

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-25 Thread Harald Armin Massa
Matthew T. O'Connor schrieb: 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 s

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Tom Lane
"Matthew T. O'Connor" 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

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Michael Paesold
Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: On Mon, Jan 24, 2005 at 06:57:54PM -0500, Tom Lane wrote: (Five minutes at least has a defensible rationale, ie it's the default checkpoint interval and we expect we can replay the log at least as fast as it was created initially.) Hmm, I

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Matthew T. O'Connor
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

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Alvaro Herrera
On Mon, Jan 24, 2005 at 06:57:54PM -0500, Tom Lane wrote: > (Five minutes at least has a defensible rationale, ie it's the default > checkpoint interval and we expect we can replay the log at least as > fast as it was created initially.) Hmm, I remember Mark Wong from OSDL saying that it took to

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > On Mon, Jan 24, 2005 at 06:57:54PM -0500, Tom Lane wrote: >> (Five minutes at least has a defensible rationale, ie it's the default >> checkpoint interval and we expect we can replay the log at least as >> fast as it was created initially.) > Hmm, I rem

Re: [PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Tom Lane
"Dave Page" writes: > 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 entirel

[PATCHES] pg_autovacuum Win32 Service startup delay

2005-01-24 Thread Dave Page
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. Regards, Dave startup_d