I ended up using a different approach...

1. I created a table called replication_heartbeat that has two columns:
id, last_modified
2. I added this table to the replication set
3. I pre-populated a single row into this table
4. I set up a cron job on the master that executes the following query
once a minute: update replication_heartbeat set last_modified=now()
5. I created Nagios alerts on both the master and the slaves that checks
this date.  On the master if the date goes stale then I know that
something is wrong with the update command in cron.  On the slaves if
the date is stale then I know something is wrong with replication.

It's a poor man's approach and it's probably silly to do all this work
when there's a built-in mechanism.  The main advantage is that it's dead
simple to understand.

--S

-----Original Message-----
From: slony1-general-bounces at lists.slony.info
[mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Vivek
Khera
Sent: Sunday, August 03, 2008 1:18 PM
To: kevin kempter
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] how to determine if the slave is caught
up/insync with the master

On Sun, Aug 3, 2008 at 12:35 PM, kevin kempter
<kevin at kevinkempterllc.com> wrote:
> Hi List;
>
> How do I know if a slave is up to date with the master ?
>

On the master, run this SQL query, replacing _CLUSTERNAME with the
name you selected for your cluster.

select * from _CLUSTERNAME.sl_status;
_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general