Skip to content

Commit 049ef33

Browse files
committed
Don't try to open visibilitymap when analyzing a foreign table
It's harmless, visibilitymap_count() returns 0 if the file doesn't exist. But it's also very pointless. I noticed this when I added an assertion in smgropen() that the relnumber is valid. Discussion: https://www.postgresql.org/message-id/621a52fd-3cd8-4f5d-a561-d510b853bbaf@iki.fi
1 parent cd7f19d commit 049ef33

File tree

2 files changed

+6
-1
lines changed

2 files changed

+6
-1
lines changed

src/backend/commands/analyze.c

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -634,7 +634,10 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
634634
{
635635
BlockNumber relallvisible;
636636

637-
visibilitymap_count(onerel, &relallvisible, NULL);
637+
if (RELKIND_HAS_STORAGE(onerel->rd_rel->relkind))
638+
visibilitymap_count(onerel, &relallvisible, NULL);
639+
else
640+
relallvisible = 0;
638641

639642
/* Update pg_class for table relation */
640643
vac_update_relstats(onerel,

src/backend/storage/smgr/smgr.c

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -153,6 +153,8 @@ smgropen(RelFileLocator rlocator, BackendId backend)
153153
SMgrRelation reln;
154154
bool found;
155155

156+
Assert(RelFileNumberIsValid(rlocator.relNumber));
157+
156158
if (SMgrRelationHash == NULL)
157159
{
158160
/* First time through: initialize the hash table */

0 commit comments

Comments
 (0)