On 04/03/20, Adrian Klaver (adrian.klaver@xxxxxxxxxxx) wrote: > On 3/4/20 2:22 PM, Rory Campbell-Lange wrote: > > On 04/03/20, Adrian Klaver (adrian.klaver@xxxxxxxxxxx) wrote: > > > On 3/4/20 2:04 PM, Rory Campbell-Lange wrote: > > > > We have many databases of the same type separated for data governance > > > > reasons. They, however, share the same web front-end code. > > > > > > > > Presently, replacing functions and performing data updates on the > > > > databases in series often executes across all databases in less than a > > > > minute. (The updates are currently done with simple sql files connecting > > > > to each database and then loading a stub file pointing to each function > > > > to drop and reload, and running the data update queries.) > > > > > > > > However, for larger updates, the time when the front end code is > > > > out-of-step with the database can cause end-user problems. > > > > > > So the issue is synchronization between the code in the database and the > > > code outside the database? > > > > > > I'm assuming the problems are changes in function signatures and return > > > values? > > > > That is one problem; sometimes we also need to make some table > > definition or data changes. > > Alright, but the general issue is that the world as seen by the database can > be different from that seen by the front end code. > > So the solution is to make those world views sync, or am I missing > something? Essentially we wish to reduce the window where the frontend and backend aren't synchronised. If we have (for example) 200 databases which each take 2 seconds to update, a client could be on the wrong frontend code for over 6 minutes. > > > > Unfortunately our schema arrangement isn't clean enough to swap out > > > > function schemas in a transaction to sort out that part of the problem > > > > (if in fact that would work anyway). > > > > > > > > One solution might be to do the updates in parallel. Another thought > > > > would be to somehow execute the code update from a text field in a table > > > > in each database triggered with pg_cron. > > > > > > > > Bearing in mind the possible problems of connection saturation or > > > > massive IO spikes, I'd be grateful to learn of any thoughts on how to > > > > negotiate this problem.
