Hi John,
Not really following you here... You said:
"...the application team only called the other DBA to fix the issue. I’d still like to know what happened."
Unless I'm missing something here, why don't you ask this "other DBA" what he/she did to "fix" the problem?
Also, not understanding this statement from you:
"...if the system simply gave up trying to keep the view’s data consistency on par..."
It almost seems as if you think the MV keeps itself updated automatically. That is not how MVs work at the present
timein the PG world. You have to manually refresh them.
Look forward to your response.
Regards,
Michael Vitale
John Scalia wrote on 12/30/2020 4:38 PM:
> Over last evening, one of my colleagues had begun recreating a materialized view. From looking at his code, it was
onlydoing some selects, like one would expect, however, several API clients ended up being blocked by this, and I’m
attemptingto understand why. I should note that a couple of the tables used here, contained more than 100 million rows,
andI’m wondering if the system simply gave up trying to keep the view’s data consistency on par, and if a more than a
non-exclusiveread block was then imposed. The API’s involved basically kept getting respawned, and at one point there
weremore than 4000 attempted simultaneous connections. Not a lot of fun, but fortunately for me, the application team
onlycalled the other DBA to fix the issue. I’d still like to know what happened.
> —
> Jay
>
> Sent from my iPad
>
