On Tue, Apr 5, 2022 at 01:10:38PM -0400, Stephen Frost wrote: > To be more explicit though- we should write a tool to do this. We > shouldn't try to document a way to do it because it's hard to get right. > While rsync is very capable, what's needed to really do this goes beyond > what we could reasonably put into any rsync command or really even into > a documented procedure. I get that we already have it documented (and > I'll note that doing so was against my recommendation..) and that some > folks (likely those who follow this mailing list) have had success using > it, but I'd really rather we just take it out and put it on a wiki > somewhere as a "we need a tool that does this stuff" and hope that > someone finds time to write one.
Well, I think pg_upgrade needs a tool, let alone for standby upgrades, but 13 years in, no one has written one, so I am not holding my breath. Also, we need to document the procedure _somewhere_ --- if we don't the only procedure is embedded in a tool. and that seems even worse than what we have now. > It should really be both- things to do on the primary ahead of time > (truncate all unlogged tables, make sure there aren't any orphaned > temporary tables, etc), and then things to do on the replicas after > shutting the primary down (basically, make sure they are fully caught up > with where the primary was at shutdown). I tried to explain that in my > prior email but perhaps didn't do a very good job. > > > Also, let me express my general terror at the idea of anyone actually > > using this procedure. > > I mean, yeah, I agree. I thought that was true for pg_upgrade in general? ;-) Seems like a pull up your sleeves and hold your nose --- I am good at those tasks. ;-) Should I work on this? Tangentially, I see that my old macros fastgetattr and heap_getattr have finally been retired by commit e27f4ee0a7. :-) -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
