我注意到在我的服务器日志中每 15 秒就会弹出一次类似的内容:
2020-01-30 21:10:30 UTC::@:[24969]:ERROR: XX000: cache lookup failed for type 0
2020-01-30 21:10:30 UTC::@:[24969]:CONTEXT: automatic vacuum of table "myschema.mytable"
2020-01-30 21:10:30 UTC::@:[24969]:LOCATION: get_typlenbyval, lsyscache.c:2036
当我手动运行时,VACUUM ANALYZE myschema.mytable;
它运行时没有任何错误,并且我的日志中的错误消失了。但是,不可避免地,它会在某个时候再次返回。
有问题的表定义如下:
tfs_dev=> \d myschema.mytable;
Table "myschema.mytable"
Column | Type | Collation | Nullable | Default
-------------+-----------+-----------+----------+---------------------------------------------------------------------------
level | text | | not null |
id | integer | | not null | nextval('myschema.mytable_id_seq'::regclass)
text_id | text | | |
name | text | | |
geom | geometry | | |
valid_dates | tstzrange | | | tstzrange(NULL::timestamp with time zone, NULL::timestamp with time zone)
adjacent | integer[] | | |
valence | integer | | |
color | smallint | | | 0
Indexes:
"mytable_pkey" PRIMARY KEY, btree (level, id)
"mytable_text_id_key" UNIQUE CONSTRAINT, btree (text_id)
"mytable_gix" gist (level, geom, id, text_id, name)
"mytable_spgix" spgist (geom)
"mytable_text_id_ix" btree (text_id, level, id, name)
Referenced by:
TABLE "otherschema.othertable" CONSTRAINT "othertable_mytable_fk" FOREIGN KEY (level, level_id) REFERENCES myschema.mytable(level, id)
TABLE "otherschema.othertable2" CONSTRAINT "othertable2_mytable_fk" FOREIGN KEY (level, level_id) REFERENCES myschema.mytable(level, id)
许多其他具有类似错误的帖子似乎是关于一个外部数据包装器,它存在于这个数据库中,但没有这个表/模式。
正如您的调查所发现的,您正遭受这个PostGIS 错误(错误编号 #4440)的困扰。
您的选择:
将 PostGIS 更新到最新的次要版本。该错误已于 2019 年 6 月修复。
解决方法:使用 GiST 而不是 SP-GiST 索引。