On 04/03/20, Adrian Klaver (adrian.klaver@aklaver.com) wrote:
> On 3/4/20 2:22 PM, Rory Campbell-Lange wrote:
> > 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.
>
> 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.