On Friday, April 4, 2014 2:32:25 PM UTC-7, Daniel Farina wrote: > > On Fri, Apr 4, 2014 at 1:42 PM, Joe Van Dyk <[email protected]<javascript:>> > wrote: > > On Friday, April 4, 2014 1:36:40 PM UTC-7, Daniel Farina wrote: > >> > >> On Fri, Apr 4, 2014 at 1:33 PM, Joe Van Dyk <[email protected]> wrote: > >> > wal-e doesn't seem to make a recovery.conf, a postgresql.conf, and a > >> > pg_subtrans directory on a backup-fetch. I had to create each of > those > >> > before I could restore. > >> > >> Well, it explicitly avoids postgresql.conf, and doesn't make a > >> recovery.conf. > > The latter it never did make, because there are recovery.conf settings > in there that WAL-E as-is doesn't know anything about, like hot > standby or where the primary_conninfo ought to be or even how to load > configuration for WAL-E. I agree it'd be nice to get to one-less-step > without losing power somehow, but it's a new surface area that to date > WAL-E has never had.
> As for avoiding postgresql.conf: my rationale is that it is full of > absolute paths and settings that can be dangerous upon restore. > Maybe make recovery.conf.sample and postresql.conf.old files? recovery.conf.sample could use the sample recovery line in the documentation, with some information gathered from how the current wal-e backup-fetch process was started. And postgresql.conf.old could contain the original master postgresql.conf file. Then, at the end of backup-fetch, tell users about two files and indicate that they should restore them or make new ones? > > The paradigm I have been using since the get-go is to always configure > a new postgresql.conf upon cluster set-up, including WAL-E restores. > This perhaps makes a bit more sense in Heroku's case, where one can > create standbys on both bigger and smaller database plan sizes where > the memory settings are totally different all the time. Heroku also > uses unique (file system) paths for every database install, so it > never occurred to me to try to keep postgres.conf the same looking in > the archives from the beginning, and its presence only represented a > foot-gun. > > But, the other side of this is not lost on me. You can see the > trade-offs in detail in this thread raised some time ago: > http://comments.gmane.org/gmane.comp.db.postgresql.wal-e/239. There's > a workaround in there too. > > >> But, pg_subtrans should show up if the primary had it. > >> Any errors in the logs of the download? > > > > > > No errors. Primary has it. > > Well that's disturbing. Uh. What's the exact path relative to > $PGDATA that's missing? I think to catch this one we'll need some > instrumentation, and if you can reproduce this then I don't want to > let this go if you have the time. > ./pg_subtrans I'll see if it can be reproduced.. -- 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.
