Skip site navigation (1) Skip section navigation (2)

Re: testing cvs HEAD - HS/SR - missing file

From: "Erik Rijkers" <er(at)xs4all(dot)nl>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>, "Erik Rijkers" <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing cvs HEAD - HS/SR - missing file
Date: 2010-01-28 00:32:58
Message-ID: 179564d7d8e0d6dc2c35baf02eef2e9a.squirrel@webmail.xs4all.nl (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, January 27, 2010 17:38, Heikki Linnakangas wrote:

> I'll commit it that way.

This is just to let you know that these commits seem to have solved the bug.

I repeated the original test (700 MB pg_restore into a primary,
with two replicating slaves, on one machine).

Checking afterwards:
$ for port in 6565 6566 6567;
do
  psql -qtAp $port -c "select pg_database_size('${PGDATABASE}'), version()";
done
17057193792|PostgreSQL 9.0devel-sr_primary [...]
17057193792|PostgreSQL 9.0devel-sr_slavery
17057193792|PostgreSQL 9.0devel-sr_slave02

So that looked promising :)  To make sure I also COPYd
all tables to file and diff'ed them. There were indeed
no differences.




I did get at one point in the sr_slave02 log: (consecutive lines)

LOG:  consistent recovery state reached at 0/2000000
LOG:  database system is ready to accept read only connections
LOG:  could not send data to client: Broken pipe
LOG:  unexpected EOF on client connection

but apparently this is not problematic?



HS/SR is a fantastic set of features.  I'll keep hammering away a bit at the dynamic duo; if you
have specific testing ideas, let me know.

Thanks!


Erik Rijkers



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-28 00:33:27
Subject: Re: Add on_perl_init and proper destruction to plperl [PATCH]
Previous:From: David E. WheelerDate: 2010-01-28 00:17:13
Subject: Re: Add on_perl_init and proper destruction to plperl [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group