Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id C9E0664FFDC
	for <pgsql-admin-postgresql.org@postgresql.org>;
	Tue,  8 Jul 2008 12:22:00 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 66801-04 for <pgsql-admin-postgresql.org@postgresql.org>;
	Tue,  8 Jul 2008 12:21:47 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from wr-out-0506.google.com (wr-out-0506.google.com
 [64.233.184.224])
	by postgresql.org (Postfix) with ESMTP id CE374650125
	for <pgsql-admin@postgresql.org>; Tue,  8 Jul 2008 12:21:46 -0300 (ADT)
Received: by wr-out-0506.google.com with SMTP id c49so1768748wra.19
	for <pgsql-admin@postgresql.org>; Tue, 08 Jul 2008 08:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:in-reply-to:mime-version:content-type:references;
	bh=sSTNMUP61kd/2H3G0CgeUsUONOVGRfbSCOt5A0jpSgA=;
	b=T1uyDkTpoXzBUp39dzR1aEMy6QJFLMnIeQNKngtlQ5bygdCLhl4HgmG75jyXT+paZo
	lkbnNUrfYe/jy0W3ofjOrHr6ZHgtkA8LYY1LNDLrSzB21YNRxYRGFPy1Eog2NtyY1Ppl
	QIAK4NLnnZk5j7BuwMSTs1mw7Qkrr8EBWN8Lk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:in-reply-to:mime-version
	:content-type:references;
	b=J52DgTGam3255tZGwbNuLV/wugWddmBfxXqlofiEXwH6rsPtEra2eYGX0bIfBHznXe
	zlHhepZ4oIOGgl06vB3W0V5WIll2XBqfoWTgqCzblxk79H7K6PBGsiW144QPjcQZhVjD
	PDtL/yxrlYR1PFb1ObDc92yvb5cQgvXISfUg8=
Received: by 10.90.30.2 with SMTP id d2mr7070378agd.118.1215530506060;
	Tue, 08 Jul 2008 08:21:46 -0700 (PDT)
Received: by 10.90.55.11 with HTTP; Tue, 8 Jul 2008 08:21:46 -0700 (PDT)
Message-ID: <407fa4640807080821w3e33c567u82fbdc4fe6d08712@mail.gmail.com>
Date: Tue, 8 Jul 2008 16:21:46 +0100
From: "Michael Nacos" <m.nacos@gmail.com>
To: pgsql-admin@postgresql.org
Subject: Re: How do i compare 2 postgresql instanses ?
In-Reply-To: <4873335D.EE98.0025.0@wicourts.gov>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_27419_17040798.1215530506057"
References: <49982.1215520948@ismartpanache.com>
	<200807081602.39336.achill@matrix.gatewaynet.com>
	<407fa4640807080620r33a3463fgff195d8ae5ef708e@mail.gmail.com>
	<4873335D.EE98.0025.0@wicourts.gov>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=AWL=-0.000,
	HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200807/87
X-Sequence-Number: 29697

------=_Part_27419_17040798.1215530506057
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks Kevin... I am working on something different right now but I'll soon
have to give it a go, one way or the other...

Michael

On Tue, Jul 8, 2008 at 3:28 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov>
wrote:

>
> Our home-grown replication technique does synchronization checks
> during idle time.  It works pretty well for us, and we do use md5sum
> techniques to minimize bandwidth.
>
> In summary, a process requests a middle tier on a "source" machine to
> send "sync" information; that middle tier reads some set of rows and
> sends the md5 sum of all data in the rows, along with information on
> what rows from which table were used to develop the number.  The
> requesting process then asks similar middle tiers on all replication
> targets to return their md5sum for the same set of rows.  If there are
> any differences, the source and all differing replication targets are
> queried for the actual values, which are compared using match-merge
> type logic on the primary key sequence.
>
> Something similar might work for you.
>
> -Kevin
>

------=_Part_27419_17040798.1215530506057
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>Thanks Kevin... I am working on something different right now but I&#39;ll soon have to give it a go, one way or the other...<br><br>Michael<br><br><div class="gmail_quote">On Tue, Jul 8, 2008 at 3:28 PM, Kevin Grittner &lt;<a href="mailto:Kevin.Grittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>Our home-grown replication technique does synchronization checks<br>
during idle time. &nbsp;It works pretty well for us, and we do use md5sum<br>
techniques to minimize bandwidth.<br>
<br>
In summary, a process requests a middle tier on a &quot;source&quot; machine to<br>
send &quot;sync&quot; information; that middle tier reads some set of rows and<br>
sends the md5 sum of all data in the rows, along with information on<br>
what rows from which table were used to develop the number. &nbsp;The<br>
requesting process then asks similar middle tiers on all replication<br>
targets to return their md5sum for the same set of rows. &nbsp;If there are<br>
any differences, the source and all differing replication targets are<br>
queried for the actual values, which are compared using match-merge<br>
type logic on the primary key sequence.<br>
<br>
Something similar might work for you.<br>
<font color="#888888"><br>
-Kevin<br>
</font></blockquote></div><br>

------=_Part_27419_17040798.1215530506057--