Daniel, Ah. To be clear, the recovery.conf in the failing case only restore_command.
Although we do use hot_standby = on when bringing up a replicated slave, so that it can pull WAL files either by WAL-E or by streaming replication, hot_standby is not on in the failing case. Thus, the only difference between the passing failing case is the addition of "--prefetch 0" to restore_command, the only config option passed into recovery.conf. -HJB On Tue, Oct 21, 2014 at 7:37 PM, Daniel Farina <[email protected]> wrote: > On Tue, Oct 21, 2014 at 7:04 PM, Hunter Blanks <[email protected]> > wrote: > > Daniel, > > > > We do have hot_standby = on. I ought to have included the > postgresql.conf. > > hot_standby=on is not the same standby_mode=on in recovery.conf. > Yeah yeah it's one of those things > http://www.postgresql.org/docs/9.3/static/standby-settings.html > > The reason for this query is that I believe postgres will *retry* when > it gets a bad wal segment in this situation, otherwise it may blow up > as you relate. This is somewhat important to avoid having WAL-E flush > prefetched WAL to disk which I took note as a serious bottleneck. > -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
