From 52e6e33ab495cb2b0e694ee480ba7c6394315053 Mon Sep 17 00:00:00 2001 From: Kevin Grittner Date: Tue, 9 Apr 2013 13:02:49 -0500 Subject: Create a distinction between a populated matview and a scannable one. The intent was that being populated would, long term, be just one of the conditions which could affect whether a matview was scannable; being populated should be necessary but not always sufficient to scan the relation. Since only CREATE and REFRESH currently determine the scannability, names and comments accidentally conflated these concepts, leading to confusion. Also add missing locking for the SQL function which allows a test for scannability, and fix a modularity violatiion. Per complaints from Tom Lane, although its not clear that these will satisfy his concerns. Hopefully this will at least better frame the discussion. --- src/backend/utils/adt/dbsize.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) (limited to 'src/backend/utils/adt/dbsize.c') diff --git a/src/backend/utils/adt/dbsize.c b/src/backend/utils/adt/dbsize.c index d589d26070d..d32d9014c7e 100644 --- a/src/backend/utils/adt/dbsize.c +++ b/src/backend/utils/adt/dbsize.c @@ -840,7 +840,8 @@ pg_relation_filepath(PG_FUNCTION_ARGS) * Indicate whether a relation is scannable. * * Currently, this is always true except for a materialized view which has not - * been populated. + * been populated. It is expected that other conditions for allowing a + * materialized view to be scanned will be added in later releases. */ Datum pg_relation_is_scannable(PG_FUNCTION_ARGS) @@ -850,9 +851,13 @@ pg_relation_is_scannable(PG_FUNCTION_ARGS) bool result; relid = PG_GETARG_OID(0); - relation = RelationIdGetRelation(relid); - result = relation->rd_isscannable; - RelationClose(relation); + relation = try_relation_open(relid, AccessShareLock); + if (relation == NULL) + PG_RETURN_BOOL(false); + + result = RelationIsScannable(relation); + + relation_close(relation, AccessShareLock); PG_RETURN_BOOL(result); } -- cgit v1.2.3