Re: Creating a materialized view causing blocks

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 time in 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 only doing some selects, like one would expect, however, several API clients ended up being blocked by this, and I’m attempting to understand why. I should note that a couple of the tables used here, contained more than 100 million rows, and I’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-exclusive read block was then imposed. The API’s involved basically kept getting respawned, and at one point there were more than 4000 attempted simultaneous connections. Not a lot of fun, but fortunately for me, the application team only called the other DBA to fix the issue. I’d still like to know what happened.
> —
> Jay
>
> Sent from my iPad
>