Galen, > - The monolithic scripts allow for consolidating multiple point updates > into a set of statements that run more quickly. Arguably this is more of a > potential for efficiency than something that has always been taken > advantage of -- but sometimes, it has. > - Of more import, since the monolithic scripts wrap all of the changes in > one or two transactions, if something goes wrong, the transaction rolls > back and the schema remains in a state that corresponds to a released > version. In contrast, if something goes wrong while going through a > sequence of point upgrades and one gets stuck, the database could be in a > state that doesn't correspond with *any* released version -- which could be > awkward if one is nearing the end of a maintenance window. Then again, if > one hasn't done a dry run first...
Yeah, I can see the advantage of the full rollback. I wonder if the wrapper/controller script I'm imagining (and Mike mentions in his "steps to make this actually happen" response could have some sort of rollback option (though I know it's Postgres transactions that we depend on for rollback at this point). > I should emphasize I'm listing some reasons why the monolithic scripts have > existed -- I'm not suggesting that they're always superior to other > approaches. Understood, thanks! -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 [email protected] http://pines.georgialibraries.org/
