Automatic vacuum fails with `ERROR: XX000: cache lookup failed for type 0`

Question

I've been noticing something like this popping up every 15 seconds in my server logs:

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

When I manually run a VACUUM ANALYZE myschema.mytable; it runs without any error, and the error in my logs goes away. However, inevitably, it returns again at some point.

The table in question is defined as follows:

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)

Many other posts with a similar error seem to be about a foreign data wrapper, which is present in this database, but not with this table/schema.

Answer 1

As your investigation uncovered, you are suffering from this PostGIS bug (bug number #4440).

Your options:

• Update PostGIS to the latest minor release. The bug has been fixed in June 2019.

• Workaround: Use GiST rather than SP-GiST indexes.