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-30 14:10:16
Message-ID: 41333548.3070408@zeut.net (view raw or flat)
Thread:
Lists: pgsql-general
I haven't had a chance to try it yet, but it looks like it will do what 
you want.

Thomas F.O'Connell wrote:
> Okay, here's a rough draft that seems to be working after some simple 
> testing:
> 
> 
> #!/bin/bash
> 
> 
> # auto_pg_autovacuum is a utility that can be used in crontab or in init
> # scripts to guarantee that pg_autovacuum is running when postgres is
> # running.
> 
> # Original Author -- Thomas F. O'Connell <tfo(at)sitening(dot)com>
> # 2004-08-28
> 
> # Assumptions:
> # 1. A sane PATH exists that includes pg_ctl and pg_autovacuum.
> # 2. pgrep exists on the system and is in PATH.
> 
> 
> # Accept an optional PGDATA override.
> # Even though -D means daemonize to pg_autovacuum, I thought this argument
> # should be consistent with the PGDATA flags for other postgresql 
> utilities.
> getopts D: opt
> [ $opt == ? ] && exit 1
> [ $OPTARG ] && PGDATA=$OPTARG
> 
> # But if we don't know where to tell pg_ctl to look for status information,
> # then we have to error out.
> if [ ! $PGDATA ]; then
>     echo "PGDATA must be set or specified as an argument to -D";
>     exit 1;
> fi
> 
> # Now check to see whether we have a postmaster.
> pg_ctl status -D $PGDATA >/dev/null
> if [ $? != 0 ]; then
>     # If we don't, there's no point starting pg_autovacuum.
>     echo "No postmaster running. Aborting.";
>     exit 1;
> fi
> 
> # Now pgrep for an exact match for pg_autovacuum.
> pgrep -x pg_autovacuum >/dev/null
> if [ $? == 0 ]; then
>     # If we find something, don't start another one.
>     echo "pg_autovacuum is already running. Aborting.";
>     exit 1;
> fi
> 
> # If we're going to start pg_autovacuum, allow specification of a logfile
> # via -L. Eventually, it would be nice to allow a -o flag or something
> # similar to allow any pg_autovacuum options to be passed through.
> getopts L: opt
> [ $OPTARG ] && LOG="-L $OPTARG"
> pg_autovacuum -D $LOG
> [ $? == 0 ] && echo "pg_autovacuum successfully started."
> 
> 
> This is also available at:
> 
> http://www.sitening.com/auto_pg_autovacuum
> 
> Eventually, we'll probably create a PostgreSQL utilities section since 
> I've got some Slony scripts underway, too.
> 
> Feedback and comments welcome. I'm not an expert shell scripter, so best 
> practices tips are especially welcome.
> 
> My apologies if this was better posted to HACKERS or a different list. 
> There's not a contrib list that I know of.
> 
> -tfo
> 
> On Aug 27, 2004, at 9:33 PM, Matthew T. O'Connor wrote:
> 
>> On Fri, 2004-08-27 at 18:09, Thomas F.O'Connell wrote:
>>
>>> Hmm. Your last point in particular is one I hadn't considered, yet,
>>> largely because it's not relevant to my current problem. For a more
>>> generalized solution, though, it should definitely be considered.
>>
>>
>> Yeah, but as you say, for what you are doing, you probably don't need to
>> worry about it.
>>
>>> Does pg_autovacuum currently store the pid of the postmaster against
>>> which it's being run? In fact, how does it know against which
>>> postmaster it's being run? It doesn't take a database as an argument,
>>> does it?
>>
>>
>> No it doesn't store the PID or anything like that and it doesn't know
>> what postmaster it's connecting to, it just connects to what ever
>> postmaster is listing to the specified host and port.
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> 

In response to

pgsql-general by date

Next:From: Stephan SzaboDate: 2004-08-30 15:26:06
Subject: Re: timestamp and date behaviour with '-infinity'
Previous:From: Vivek KheraDate: 2004-08-30 13:58:05
Subject: Re: Deadlocks caused by referential integrity checks

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