On Mon, Dec 30, 2013 at 9:11 PM, Sergey Konoplev <gray...@gmail.com> wrote:
> On Mon, Dec 30, 2013 at 8:56 PM, Joe Van Dyk <j...@tanga.com> wrote: > > On Mon, Dec 30, 2013 at 10:27 AM, Sergey Konoplev <gray...@gmail.com> > wrote: > >> On Mon, Dec 30, 2013 at 12:02 AM, Joe Van Dyk <j...@tanga.com> wrote: > >> > On Sun, Dec 29, 2013 at 10:52 PM, Sergey Konoplev <gray...@gmail.com> > >> > wrote: > >> >> On Sun, Dec 29, 2013 at 9:56 PM, Joe Van Dyk <j...@tanga.com> wrote: > >> >> > On Wed, Dec 18, 2013 at 3:39 PM, Sergey Konoplev < > gray...@gmail.com> > >> >> > wrote: > >> >> > If I run "COPY (select * from complicate_view) to stdout" on the > >> >> > standby, > >> >> > I've noticed that sometimes halts replication updates to the slave. > >> >> > >> >> \x > >> >> select * from pg_stat_repication; > >> > >> And it would be very useful to take a look at your checkpoints and > >> replication configuration parameters on both master and replica. > > > > master and replica have same settings. > > > > checkpoint_completion_target: 0.9 > > checkpoint_segments: 16 > > checkpoint_timeout: 5m > > checkpoint_warning: 30s > > hot_standby: on > > hot_standby_feedback: on > > I meant all the replication settings, see [1]. And pg_stat_statements > when there is a problem, preferable the error, because when everything > is okay it is not very useful actually. > I don't understand, how is pg_stat_statements helpful here, and what error? > > [1] > http://www.postgresql.org/docs/9.3/static/runtime-config-replication.html max_wal_senders: 5 wal_keep_segments: 10000 wal_sender_timeout: 1m synchronous_standby_names: n/a vacuum_defer_cleanup_age: 0 max_standby_archive_delay: 30s max_standby_streaming_delay: -1 wal_receiver_status_interval: 10s hot_standby_feedback: on wal_receiver_timeout: 1m
