On Mon, Mar 15, 2021 at 10:38 AM Thomas Munro <thomas.mu...@gmail.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
