> > Your output indicates that there is a problem in your replication
> > setup and this is why the slave does not catch up.
> >
> > This is not a performance issue. It is either a bug in replication, or
> > a user configuration issue. Since few things have changed in 9.1 in
> > this area, at the moment the balance of probability is towards user
> > error. If you can provide a more isolated bug report we may be able to
> investigate.
>
> Apologies for the double post, I thought to have understood that in your
> previous message.
>
> I've read the online 9.1 manual and configured the clusters based on that
> information (and on the defaults provided by debian). I've attached the
> postgresql.conf files I'm using for master and slave. Do you need other
> information from my final setup? Log files, configuration files, the SQL script fed
> to psql, which shows the slow replication...?
I've been looking at my log files on master and slave a bit better, after having set log_min_messages = debug5. I can see that 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 administrator command', while the master is sending data ('write/flush/apply') (the next part of the WAL?), and then 'could not send data to the client: Connection reset by peer', after which the server process exits. I'm hoping this provides you 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, where you can see the above behavior.
Hoping that this will bring me a bit closer to a solution or a proper bug report,
David Hartveld
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
