Re: Streaming Replication patch for CommitFest 2009-09 - Mailing list pgsql-hackers

This is looking really neat now, making async replication really solid 
first before even trying to move on to sync is the right way to go here 
IMHO.  I just cleaned up the docs on the Wiki page, when this patch is 
closer to being committed I officially volunteer to do the same on the 
internal SGML docs; someone should nudge me when the patch is at that 
point if I don't take care of it before then.

Putting on my DBA hat for a minute, the first question I see people asking 
is "how do I measure how far behind the slaves are?".  Presumably you can 
get that out of pg_controldata; my first question is whether that's 
complete enough information?  If not, what else should be monitored?

I don't think running that program going to fly for a production quality 
integrated replication setup though.  The UI admins are going to want 
would allow querying this easily via a standard database query.  Most 
monitoring systems can issue psql queries but not necessarily run a remote 
binary.  I think that parts of pg_controldata needs to get exposed via 
some number of built-in UDFs instead, and whatever new internal state 
makes sense too.  I could help out writing those, if someone more familiar 
with the replication internals can help me nail down a spec on what to 
watch.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] 8.5 plpgsql change for named notation: treat word following AS keyword as label v3
Next
From: Pavel Stehule
Date:
Subject: Re: [PATCH] 8.5 plpgsql change for named notation: treat word following AS keyword as label v3