Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW

On Mon, Mar 15, 2021 at 10:38 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> While reading some back history, I saw that commit e9baa5e9 introduced
> parallelism for CREATE M V, but REFRESH was ripped out of the original
> patch by Robert, who said:
>
> > The problem with a case like REFRESH MATERIALIZED VIEW is that there's
> > nothing to prevent something that gets run in the course of the query
> > from trying to access the view (and the heavyweight lock won't prevent
> > that, due to group locking). That's probably a stupid thing to do,
> > but it can't be allowed to break the world. The other cases are safe
> > from that particular problem because the table doesn't exist yet.

Please correct me if my understanding of the above comment (from the
commit e9baa5e9) is wrong - even if the leader opens the matview
relation in exclusive mode, because of group locking(in case we allow
parallel workers to feed in the data to the new heap that gets created
for RMV, see ExecRefreshMatView->make_new_heap), can other sessions
still access the matview relation with older data?

I performed below testing to prove myself wrong for the above understanding:
session 1:
1) added few rows to the table t1 on which the mv1 is defined;
2) refresh materialized view mv1;

session 2:
1) select count(*) from mv1; ---> this query is blocked until
session 1's step (2) is completed and gives the latest result even if
the underlying data-generating query runs select part in parallel.

Is there anything I'm missing here?

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com