On Sep 23, 2012, at 6:13 PM, Tomasz Pala <go...@polanet.pl> wrote: > On Sun, Sep 23, 2012 at 17:56:55 -0400, Jeffrey Johnson wrote: > >> Which is what I said *repeatedly* in an attempt to adjust expectations of >> --rollback. Go read the Blablabla ... > > Whose expectations would you like to adjust? Seriously - you want _us_ to > expect rollback to work on global fs state? You must be an idiot then! The > question was: how to downgrade repackaged package set specifying the time > factor. > You insist on irrevelant shit. >
troll++ >>> 3. "when the disk isn't/wasn't working properly, every solution is utterly >>> useless" >> >> You are clueless: saving state remotely permits an >> entire machine to be recreated when hard drives fail. > > Try running replicated postgresql master node on failing drive and share > your results! > Why? The issue(s) involved with maintaining databases consistently with package manager upgrades are non-trivial to solve with a perl script like yours. >> Backups and off-site storage are well known remedies >> for hard drive failures. > > Only when drive fails _after_ the backup was made. If my clock was set > properly during upgrades, my perl would select proper directories. > So write a perl sc riot that permits upgrading postgresql masters now that you have solved --rollback with one line of perl. Surely you can hack out a postgresql master software upgrade by next week instead of wasting time trolling me. 73 de Jeff > -- > Tomasz Pala <go...@pld-linux.org> > _______________________________________________ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
