From 503c80d2a0da77686c2549c37a4b0033c5f4a95a Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 2 Apr 2001 23:30:04 +0000
Subject: [PATCH] Restore pre-7.1 behavior of allowing DROP of a table whose
underlying physical file has disappeared. There is no really good reason why
relcache should be opening the underlying file at all, AFAICS. In any case we
needn't raise a hard error here.
---
src/backend/utils/cache/relcache.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index a92f65add5d..352f52e9208 100644
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.130 2001/03/23 04:49:55 momjian Exp $
+ * $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.131 2001/04/02 23:30:04 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -1125,12 +1125,21 @@ RelationBuildDesc(RelationBuildDescInfo buildinfo,
relation->rd_node.relNode = relation->rd_rel->relfilenode;
/*
- * open the relation and assign the file descriptor returned by the
+ * Open the relation and assign the file descriptor returned by the
* storage manager code to rd_fd.
*
+ * We do not raise a hard error if we fail to open the relation at this
+ * point. If we did, it would be impossible to drop a relation whose
+ * underlying physical file had disappeared.
*/
if (relation->rd_rel->relkind != RELKIND_VIEW)
- relation->rd_fd = smgropen(DEFAULT_SMGR, relation, false);
+ {
+ relation->rd_fd = smgropen(DEFAULT_SMGR, relation, true);
+ Assert(relation->rd_fd >= -1);
+ if (relation->rd_fd == -1)
+ elog(NOTICE, "RelationBuildDesc: can't open %s: %m",
+ RelationGetRelationName(relation));
+ }
else
relation->rd_fd = -1;
--
GitLab