Daniel, We do have hot_standby = on. I ought to have included the postgresql.conf. Notable settings on this particular box are:
wal_level = archive # archive_mode (default) # archive_command (default) max_wal_senders = 5 # max number of walsender processes (if master) hot_standby = on # "on" allows queries during recovery (if not master) Thus, when in recovery, we do allow queries, since in production, we want a hot standby brought up with WAL-E (and replicating indefinitely due to recovery.conf that also contains a hot standby host) to be able to serve queries. -HJB On Tue, Oct 21, 2014 at 5:58 PM, Daniel Farina <[email protected]> wrote: > On Tue, Oct 21, 2014 at 5:27 PM, <[email protected]> wrote: > > Hi, > > > > After upgrading from 0.7.2 to 0.8c1, I've noticed that my typical run of > > wal-e backup-fetch + wal-fetch in recovery.conf now fails unless I > disable > > prefetching. This ultimately means that PostgreSQL will fail to start > after > > a backup-fetch. The logs from a successful restore / recovery without > > prefetch and a failed restore / recovery with it are included below. > > Uh oh. That sounds like a stop-ship bug although I haven't encountered > it myself. Looks like somehow what is a 404 gets translated to an > empty file and then hilarity ensues. > > Are you using standby_mode=on by any chance? > -- 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.
