Lock relation used to generate fresh data for RMV.

Back-patch the 9.4-era commit 2636ecf78 into 9.3, as that fixes a case
where we open a relation while not holding any lock on it.  It's
probably mostly safe anyway, since no other session could touch the
newly-created table; but I think CheckTableNotInUse could be fooled
if one tried.

Per testing with a patch that complains if we open a relation without
holding any lock on it.  I don't plan to back-patch that patch, but we
should close the holes it identifies in all supported branches.

Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us

diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c
index f2edece89cdce9c9aa77fe4deb6826d8ae1d157e..374325c3c02e4c568589c7fdfc9d219a25a7058c 100644 (file)
--- a/src/backend/commands/matview.c
+++ b/src/backend/commands/matview.c
@@ -26,6 +26,7 @@
 #include "executor/executor.h"
 #include "miscadmin.h"
 #include "rewrite/rewriteHandler.h"
+#include "storage/lmgr.h"
 #include "storage/smgr.h"
 #include "tcop/tcopprot.h"
 #include "utils/rel.h"
@@ -208,8 +209,13 @@ ExecRefreshMatView(RefreshMatViewStmt *stmt, const char *queryString,
 
        tableSpace = matviewRel->rd_rel->reltablespace;
 
-       /* Create the transient table that will receive the regenerated data. */
+       /*
+        * Create the transient table that will receive the regenerated data. Lock
+        * it against access by any other process until commit (by which time it
+        * will be gone).
+        */
        OIDNewHeap = make_new_heap(matviewOid, tableSpace);
+       LockRelationOid(OIDNewHeap, AccessExclusiveLock);
        dest = CreateTransientRelDestReceiver(OIDNewHeap);
 
        /* Generate the data, if wanted. */