Skip site navigation (1) Skip section navigation (2)

Re: pg_autovacuum start-script

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: "Thomas F(dot)O'Connell" <tfo(at)sitening(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_autovacuum start-script
Date: 2004-08-27 21:47:49
Message-ID: 412FAC05.6060202@zeut.net (view raw or flat)
Thread:
Lists: pgsql-general
Thomas F.O'Connell wrote:
> On Aug 27, 2004, at 3:37 PM, Matthew T. O'Connor wrote:
>> pg_autovacuum will exit when it can no longer connect to a postmaster. 
>> The problem is that it might sleep for several minutes before it 
>> notices that the postmaster has shutdown.  So, you can restart the 
>> postmaster and as long as pg_autovacuum never noticed that it went 
>> away, it will keep chugging along as if nothing happened.
>>
>> Is there anyway pg_autovacuum can know if the postmaster has 
>> restarted?  New PID? Or something better?
> 
> Hmm. If the above situation is true, does it matter whether 
> pg_autovacuum knows whether the postmaster restarted?

The issue is knowing if you need to launch another pg_autovacuum 
process, you certainly don't want to have two pg_autovacuum processes 
running against the same server.

>>> Is this logic sufficiently sane?
>>
>> Well if the script also sends a kill signal to pg_autovacuum that 
>> might solve the pg_autovacuum still running problem.
> 
> Based on what you say above, though, is it even necessary to kill it? 
> Why not just observe that it's running and fail to start a new one? 
> Unless there's a need to restart pg_autovacuum if postmaster restarts.

Perhaps not as long as you can reliably observe that it's running 
against the newly started postmaster and not another pg_autovacuum 
process running against an entirely separate postmaster process.


In response to

Responses

pgsql-general by date

Next:From: Jon AsherDate: 2004-08-27 22:03:34
Subject: Problem with sql COPY command
Previous:From: Joshua D. DrakeDate: 2004-08-27 21:16:46
Subject: Re: Deadlocks caused by referential integrity checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group