On Tue, Oct 21, 2014 at 10:31 PM, Hunter Blanks <[email protected]> wrote: > Daniel, > > On Tue, Oct 21, 2014 at 10:12 PM, Daniel Farina <[email protected]> wrote: >> >> So, no standby_mode = on in recovery.conf? Can you give that a try >> and user the "trigger file" to come out of recovery? > > > I'll give that a try in the AM and let you know how it goes. I'd imagine it > should work fine, although it probably doesn't fix the root problem. For > development environments, we almost always automate WAL-E recovery up to the > last checkpoint and then kick it out of recovery. Requiring standby_mode = > on makes it so the provisioner has to figure out when to take the machine > out of recovery. Doing that right seems a little tricky.
Yeah, it probably should be fixed, but there are Reasons. I personally can't work up any enthusiasm for the standby_mode=off contract, because any interesting exit code kicks Postgres out of recovery. OOM of wal-e or the shell that spawns it, Python segfaults, any WAL-E bug, you name it: unfortunately there is no contract whereby the de-archiver can say "there really was no file there" rather than "I exited non-normally for any reason" (and, if one has problems with shell, envdir, or whatever, then WAL-E may not even get a chance to execute). I think for the sake of "it should just work" this behavior can be fixed...there is no reason to promote empty files or create them in 404 situations, but therein lies why this bug was not found by Heroku Postgres via me. -- 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.
