On Aug 5, 2008, at 11:41 AM, Shahaf Abileah wrote:

> 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
>
>


Is there  documentation someone can point me towards that defines with  
some detail all the columns of the sl_status table, or even better all  
the _CLUSTERNAME tables ?