On 04/03/20, Adrian Klaver (adrian.klaver@aklaver.com) 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.
> > 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.