Re: pg_autovacuum start-script - Mailing list pgsql-general

From Matthew T. O'Connor
Subject Re: pg_autovacuum start-script
Date
Msg-id 41333548.3070408@zeut.net
Whole thread Raw
In response to pg_autovacuum start-script  (Thomas F.O'Connell <tfo@sitening.com>)
List 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@sitening.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@postgresql.org)
>

pgsql-general by date:

Previous
From: Vivek Khera
Date:
Subject: Re: Deadlocks caused by referential integrity checks
Next
From: Stephan Szabo
Date:
Subject: Re: timestamp and date behaviour with '-infinity'