Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id D1AC11337B5B
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Mon, 20 Dec 2010 15:31:03 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 17571-03 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Mon, 20 Dec 2010 19:30:57 +0000 (UTC)
X-Greylist: delayed 00:08:11.790214 by SQLgrey-1.7.6
Received: from hermes.vectorsf.com (firewall.vectorsf.com [62.82.80.62])
	by mail.postgresql.org (Postfix) with ESMTP id 34375133616B
	for <pgsql-admin@postgresql.org>; Mon, 20 Dec 2010 15:30:56 -0400 (AST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by hermes.vectorsf.com (Postfix) with ESMTP id 7FCD411C0165
	for <pgsql-admin@postgresql.org>; Mon, 20 Dec 2010 20:22:39 +0100 (CET)
X-Virus-Scanned: amavisd-new at hermes.vectorsf.com
Received: from hermes.vectorsf.com ([127.0.0.1])
	by localhost (hermes.vectorsf.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id K98+NPBiKsZe for <pgsql-admin@postgresql.org>;
	Mon, 20 Dec 2010 20:22:39 +0100 (CET)
Received: from [192.168.25.110] (unknown [192.168.25.110])
	(Authenticated sender: imartinez)
	by hermes.vectorsf.com (Postfix) with ESMTPSA id 17E7A11C00BD
	for <pgsql-admin@postgresql.org>; Mon, 20 Dec 2010 20:22:38 +0100 (CET)
Subject: Data duplication when moving datafiles from one server to another.
From: =?ISO-8859-1?Q?I=F1igo?= Martinez Lasala <imartinez@vectorsf.com>
To: pgsql-admin@postgresql.org
Content-Type: multipart/alternative; boundary="=-N9s5KU8TL05Gq3Yvypu9"
Date: Mon, 20 Dec 2010 20:22:40 +0100
Message-ID: <1292872960.20992.8.camel@deimos>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-4.209 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201012/134
X-Sequence-Number: 36363


--=-N9s5KU8TL05Gq3Yvypu9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Good evening.

Yesterday we experienced some data duplication in several database
tables after one sysadmin decided to test in a production environment an
rsync script in order to migrate a database from one server to another
one.
Postgresql (8.2) was running in source server and rsync script was
launched from second one. Second one server had a one day old copy of
the same database. Rsync script create a datafile replica in destination
server. 
Our sysadmin swear he didn't launch the script in a reverse way (that
is, from destination to source)... so my question is
How this data duplication could happen? Due to an rsync lock in
checkpoint segment or transaction logs? Or he has mistaken source with
destination server?

Thans in advance.



--=-N9s5KU8TL05Gq3Yvypu9
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
Good evening.<BR>
<BR>
Yesterday we experienced some data duplication in several database tables after one sysadmin decided to test in a production environment an rsync script in order to migrate a database from one server to another one.<BR>
Postgresql (8.2) was running in source server and rsync script was launched from second one. Second one server had a one day old copy of the same database. Rsync script create a datafile replica in destination server. <BR>
Our sysadmin swear he didn't launch the script in a reverse way (that is, from destination to source)... so my question is<BR>
How this data duplication could happen? Due to an rsync lock in checkpoint segment or transaction logs? Or he has mistaken source with destination server?<BR>
<BR>
Thans in advance.<BR>
<BR>
<BR>
</BODY>
</HTML>

--=-N9s5KU8TL05Gq3Yvypu9--