On 3/4/20 4:33 PM, Rory Campbell-Lange wrote:
> 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.
The only solution to that is parallel updates (not all 200 at once!!) with a
progress bar.
>>>>> 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.
>
--
Angular momentum makes the world go 'round.