Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 503c80d

Browse files
committed
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.
1 parent 244fd47 commit 503c80d

File tree

1 file changed

+12
-3
lines changed

1 file changed

+12
-3
lines changed

src/backend/utils/cache/relcache.c

+12-3
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.130 2001/03/23 04:49:55 momjian Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.131 2001/04/02 23:30:04 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -1125,12 +1125,21 @@ RelationBuildDesc(RelationBuildDescInfo buildinfo,
11251125
relation->rd_node.relNode = relation->rd_rel->relfilenode;
11261126

11271127
/*
1128-
* open the relation and assign the file descriptor returned by the
1128+
* Open the relation and assign the file descriptor returned by the
11291129
* storage manager code to rd_fd.
11301130
*
1131+
* We do not raise a hard error if we fail to open the relation at this
1132+
* point. If we did, it would be impossible to drop a relation whose
1133+
* underlying physical file had disappeared.
11311134
*/
11321135
if (relation->rd_rel->relkind != RELKIND_VIEW)
1133-
relation->rd_fd = smgropen(DEFAULT_SMGR, relation, false);
1136+
{
1137+
relation->rd_fd = smgropen(DEFAULT_SMGR, relation, true);
1138+
Assert(relation->rd_fd >= -1);
1139+
if (relation->rd_fd == -1)
1140+
elog(NOTICE, "RelationBuildDesc: can't open %s: %m",
1141+
RelationGetRelationName(relation));
1142+
}
11341143
else
11351144
relation->rd_fd = -1;
11361145

0 commit comments

Comments
 (0)