On Wed, Oct 22, 2014 at 1:08 PM, Hunter Blanks <[email protected]> wrote: > Daniel, > > Thanks for writing. Setting standby_mode = on and then triggering end of > recovery with trigger_file does work, regardless of whether prefetch is > enabled. More logs follow. > > I share your sympathies on the limitations of "exit-code-as-interface" we > get from PostgreSQL's restore_command. Of course, since we've daemonized > wal-prefetch, it doesn't actually matter if we exit non-zero? Couldn't we > just raise an exception if do_lzop_get() returns false?
Yeah. That fix I think is quite tractable in a number of ways, including that one. Care to whip up a test (if not a huge pain) and patch? If you don't have time to do it soon, I will, since there is a release pending. The other matter of dealing with crashes (unfortunately by experiment in my first design, syncing the WAL prefetched in this way is a meaningful bottleneck in practical scenarios) is a bit more troublesome. I have my design above (boot-time based) which is not even quite 100% in events like messing with mounts. And I'm not keen on something heavyhanded that punishes the common case for a vanishingly small (or, zero in the case of standby_mode=on) to solve the problem "completely". I think I may leave the crash recovery case as defect for now. -- 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.
