Re: Streaming replication on 9.1-beta2 after pg_restore is very slow - Mailing list pgsql-general

From Simon Riggs
Subject Re: Streaming replication on 9.1-beta2 after pg_restore is very slow
Date
Msg-id CA+U5nMJD4LS2=orsOOgU+sKapTmn3-_fmox_u5fjvnc7JjAUeA@mail.gmail.com
Whole thread Raw
In response to Re: Streaming replication on 9.1-beta2 after pg_restore is very slow  (David Hartveld <David.Hartveld@mendix.com>)
List pgsql-general
On Thu, Jul 7, 2011 at 2:59 PM, David Hartveld
<David.Hartveld@mendix.com> wrote:

> I've been looking at my log files on master and slave a bit better, after having set log_min_messages = debug5. I can
seethat somehow the master and slave don't properly work together: the slave attempts to send some data ('sending
write/flush/apply')(I'm assuming this is the slaves current location in the WAL?) and then 'terminates process due to
administratorcommand', while the master is sending data ('write/flush/apply') (the next part of the WAL?), and then
'couldnot send data to the client: Connection reset by peer', after which the server process exits. I'm hoping this
providesyou with more information on what is going on. Do point me in the right direction if you need me to investigate
further.I have attached two pieces of the master and slave log files, which should correspond w.r.t. their interaction,
whereyou can see the above behavior. 

Ah, so synchronous_standby_names is set on the standby.

Please reset that so we are operating asynchronously, then rerun tests
to see if that avoids the error. You'll probably need to fully
re-generate the standby server before doing this.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-general by date:

Previous
From: salah jubeh
Date:
Subject: Re: Oracle to Postgres migration open source tool
Next
From: Jeff Davis
Date:
Subject: Re: Latency problems with simple queries