Error cache lookup failed for type

Steps to reproduce

We run a stored procedure

CREATE OR REPLACE FUNCTION refresh_table(p_SearchTableName text, p_TableName text, p_IdType int) RETURNS BOOLEAN AS $$
DECLARE    
	drop_statement text;
	create_statement text;
	reporting_table text;
BEGIN
		
	-- remove special characters
	reporting_table :=  regexp_replace(lower(p_TableName), '[^a-z]+', '', 'g');

	drop_statement := 'DROP TABLE IF EXISTS ' || reporting_table || ' cascade';

	create_statement := 'CREATE UNLOGGED TABLE '|| reporting_table || ' (ID serial PRIMARY KEY, '
--... columns ...			
	')' ;


		EXECUTE drop_statement;				
		EXECUTE create_statement;
	RETURN TRUE;
END;
$$ LANGUAGE 'plpgsql'
 SECURITY DEFINER;

then using the same connection we call conn.ReloadTypes();

after that we open a new connection just to be sure and also call conn.ReloadTypes() in case its part of a connection pool and the connection has types cached.

	using (var conn = new NpgsqlConnection(connectionString)) {
				conn.Open();
				//https://stackoverflow.com/questions/51086421/npgsql-postgresexception-0x80004005-xx000-cache-lookup-failed-for-type-20785
				conn.ReloadTypes();
using (var cmd = new NpgsqlCommand(insertSQL, conn)) {
// insert stuff..
...
cmd.ExecuteNonQuery();
// exception thrown here

The issue

Exception thrown: XX000: cache lookup failed for type 0

If you are seeing an exception, include the full exceptions details (message and stack trace).

Exception message:
Stack trace:
XX000: cache lookup failed for type 0 at Npgsql.NpgsqlConnector.<>c__DisplayClass160_0.<<DoReadMessage>g__ReadMessageLong|0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- 
at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming) 
at Npgsql.NpgsqlDataReader.NextResult() at Npgsql.NpgsqlCommand.ExecuteReaderAsync(CommandBehavior behavior, Boolean async, CancellationToken cancellationToken) at Npgsql.NpgsqlCommand.ExecuteNonQuery(Boolean async, CancellationToken cancellationToken) 
at Npgsql.NpgsqlCommand.ExecuteNonQuery() 
at ReportPublisher.PublishEntityTypeAsync[TEntityType,TEntity](String typeName, String type, TEntityType entityType, MiddlewareClient cl, IList`1 entityMeta, CancellationToken cancellationToken)
 or

 Npgsql.PostgresException : XX000: cache lookup failed for type 0at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at async Npgsql.NpgsqlConnector.<>c__DisplayClass160_0.<DoReadMessage>g__ReadMessageLong|0(??)
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at async Npgsql.NpgsqlDataReader.NextResult(??)
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Npgsql.NpgsqlDataReader.NextResult()
 at async Npgsql.NpgsqlCommand.ExecuteReaderAsync(??)
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at async Npgsql.NpgsqlCommand.ExecuteNonQuery(??)
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Npgsql.NpgsqlCommand.ExecuteNonQuery()
 at async ReportPublisher.PublishEntityTypeAsync[TEntityType,TEntity](String typeName,String type,TEntityType entityType,MiddlewareClient cl,IList`1 entityMeta,CancellationToken cancellationToken)

### Further technical details

Npgsql version: 5.0.3
PostgreSQL version: PostgreSQL 10.11, compiled by Visual C++ build 1800, 64-bit
Operating system: Windows Server 2019 (azure)

Other details about my project setup:
The code is running in an azure function, so there would be connection pooling.

09.07.12 — 16:19

1 — 09.07.12 — 16:27

как говориться, ответ заложен в вопросе — postresql

2 — 09.07.12 — 16:29

ха, а в этом случае УТ11+317+postgresql …

3 — 09.07.12 — 16:31

и каков ответ?

4 — 09.07.12 — 16:31

на сайте гилева все расписано.

(0) постгри небось, неадаптирован к 1с?

5 — 09.07.12 — 16:32

+ платформа относительно нестарая, а вот постгри давно 9-ку ставят (я, например).

6 — 09.07.12 — 16:33

ответ на счет адаптации в версии. что древний — согласен, но не нашел корректной инструкции как лучше обновить с моей версии, до текущей.

7 — 09.07.12 — 16:34

(6) скачай готовый любой версии с эзерсофта. или собирай из сырцов с офф сайта.

8 — 09.07.12 — 16:35

скачал, тупо накатать на текущий? ну естественно pg_dumpall сделав предварительно.

9 — 09.07.12 — 16:38

кстати, сейчас попробовал «тестирование и исправление» на логику, такой же вылет…

10 — 09.07.12 — 16:38

(8) выгрузи базу в dt, поставь все новое и вгрузи обратно. все.)

11 — 09.07.12 — 16:39

я — за свежеустановленные сервера. не стоит мелочиться.)

12 — 09.07.12 — 16:41

судя по последним исследованиям — БД имеет логические ошибки. не в серваках дело и не в релизах.

13 — 09.07.12 — 16:51

14 — 09.07.12 — 17:00

еще бы знать как пересоздать slony… и зачем она вообще…

15 — 10.07.12 — 10:11

«Тестирование и исправление» не спасло ситуацию. Делал так: выгрузил в dt, создал файловую БД, тестирование и исправление только на логическую целостность, затем обратно dt в базу. Ошибка та же. Кроме как обновить на Postgre 9-ый есть мысли?

16 — 10.07.12 — 12:18

Может «ап» спасет ситуацию?

17 — 10.07.12 — 12:49

на юзерс последняя совместимая с 1с версия постгри 9.1.2-1.1C. Может это поможет?

18 — 10.07.12 — 12:50

8.4.3-3.1C        18.05.2010    июльский выпуск 2010 г.

а платформа 1с новая. Попробуй.

19 — 10.07.12 — 12:53

Я понимаю, что желательно обновить СУБД, но не нашел в гугле ни одной «адекватной» инструкции по обновлению.

20 — 10.07.12 — 12:55

Причем система работала ранее… Причем с ней (системой) ничего не делали, есть подозрение что вырубался свет, УПС мог не простоять долго.

21 — 10.07.12 — 13:25

22 — 10.07.12 — 13:30

Перезапускал…

23 — 10.07.12 — 13:39

может такое быть, что при загрузке в базу из дт, какие-то кэши сохраняются? Попробуй тогда vacuum тот же запустить

24 — 10.07.12 — 13:49

Ок, как его (vacuum) запустить?

25 — 10.07.12 — 13:52

Может тупо пересоздать базу?

26 — 10.07.12 — 13:54

27 — 10.07.12 — 13:58

а что конкретно выбирать full fize analize?

28 — 10.07.12 — 13:58

кстати вряд ли dt что либо от СУБД хранит в себе…

29 — 10.07.12 — 14:07

фул выбери

30 — 10.07.12 — 14:08

ок, буду пробовать…

31 — 10.07.12 — 16:52

Пока вроде помогло прибить/восстановить базу, через консоль сервера 1С. Будем дальше наблюдать…

32 — 10.07.12 — 18:57

33 — 11.07.12 — 09:21

Грохнул на серваке 1С, но там есть пункт «Удалить базу целиком», т.е. на постгре она тоже грохнулась. Предварительно сделал dt. Сегодня пользователи уже не могут смоделировать ошибку. Параллельно написал в саппорт 1С, запросили логи и дампы ТЖ, отправил, жду ответа, если ответ будет адекватным, напишу здесь.

34 — 11.07.12 — 10:10

(33) пасибо. имхо трабл в постгри, а не сервере 1с (ты же его перезагружал). А это значит что при загрузке дт в существующую базу на постгри какая то часть кеша остается

35 — 11.07.12 — 18:02

Ответ саппорта не удивил: Нужно попробовать PostgreSQL 9.1.2.

Если ошибка воспроизведется, то для расследования нужна будет ваша базу

36 — 11.07.12 — 21:35

(35) Ну так попробуйте, тем более, что эту версию сегодня перевели в промышленную эксплуатацию, до этого полгода она висела в тестовой. И 318-ю заодно попробуйте.

37 — 12.07.12 — 09:41

100500 раз, я не владею полноценной инструкцией, как правильно обновить постгре. если кто знает где она есть — ткните носом. проблема на текущий момент решена через полное удаление БД и создание заново загрузкой dt.

38 — 12.07.12 — 09:44

и судя по users.v8.1c.ru перевели постгре 10.02.2012, а не «сегодня»

39 — 12.07.12 — 09:49

(19) Выгрузить в *.dt, снести все накуй, поставить заново, заново настроить конфиги. Иначе риск того, что косяк переплывет в новую версию здоровенный. Вдруг у Вас просто конфиг некорректно настроен?

40 — 12.07.12 — 09:56

а какие то преимущества 9 версия postgres дает по сравнению с 8.3.8? именно при работе с 1с.

41 — 12.07.12 — 11:19

(40) Глупый чтоль? Цифра больше!

42 — 12.07.12 — 11:45

(40) hot backup

43 — 12.07.12 — 12:17

Еще раз, база сейчас в рабочем состоянии. Обновлять на 9-ый постгре без адекватной инструкции не вижу смысла (как раз для данной темы остался пока нерешенным). У кого есть инструкция или кто ее в состоянии черкануть, не поленитесь, поделитесь.

44 — 12.07.12 — 12:58

(38) На users.v8.1c.ru  с 10.02.2012 она была тестовой, а вчера ее переместили в промышленную, с то же датой. Видимо, никаких изменений в дистрибутив не вносилось и дату не меняли.

(43) В (39) исчерпывающая инструкция, по крайней мере для Windows.

45 — 12.07.12 — 13:35

46 — 12.07.12 — 13:39

Ок, обновление и установка две разные вещи, я так думал. Ладно, тема исчерпала свое.

I’m currently working on a PostgreSQL 9.2.x Database with a lots of Clients, and tables and functions. We deploy code constantly and sometimes it is necessary to even drop a type or a function due this deployment.

Example:

1.Script to create the needed functions in the first place

CREATE TYPE tmp._myEnum AS ENUM ('OLD', 'NEW', 'BOTH'); 

CREATE OR REPLACE FUNCTION tmp._get_status()
RETURNS tmp._myEnum AS
$BODY$
BEGIN
    RETURN 'OLD'::tmp._myEnum;
END;
$BODY$
LANGUAGE plpgsql VOLATILE SECURITY DEFINER COST 10;


CREATE OR REPLACE FUNCTION tmp._my_testfunction()
RETURNS VOID AS
$BODY$
BEGIN
    CASE tmp._get_status()
        WHEN 'OLD'::tmp._myEnum THEN 
            RAISE INFO 'myEnum is OLD';
        WHEN 'NEW'::tmp._myEnum THEN 
            RAISE INFO 'myEnum is NEW';
        WHEN 'BOTH'::tmp._myEnum THEN 
            RAISE INFO 'myEnum is BOTH';
        ELSE
            RAISE INFO 'myEnum has an unexpected value';
    END CASE;

    FOR i IN 1..10 LOOP
        RAISE INFO 'Step [%]',i;
    END LOOP;
    RETURN;
END;
$BODY$
LANGUAGE plpgsql VOLATILE SECURITY DEFINER COST 10;

2.Scenario that leads to the exception:

a)One Client is constantly using tmp._my_testfunction() like this

SELECT tmp._my_testfunction()

b)In order to deploy a change to the Composite type i execute in another session

DROP FUNCTION IF EXISTS tmp._get_status();
DROP TYPE IF EXISTS tmp._myEnum;

CREATE TYPE tmp._myEnum AS ENUM ('OLD', 'NEW', 'BOTH','NOTHING'); 

CREATE OR REPLACE FUNCTION tmp._get_status()
RETURNS tmp._myEnum AS
$BODY$
BEGIN
    RETURN 'OLD'::tmp._myEnum;
END;
$BODY$
LANGUAGE plpgsql VOLATILE SECURITY DEFINER COST 10;

c)The Client that is constantly using tmp._my_testfunction() imidiatly throws

ERROR:  cache lookup failed for type 386318
CONTEXT:  PL/pgSQL function tmp._my_testfunction() line 3 at CASE

How can I prevent that?

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.

Вэнь предварительно написание

Как член кода сельское хозяйство, вам нужно постоянное обучение. В моей работе некоторые аналитические сводки и учебные заметки будут написаны в качестве блога, чтобы общаться с вами, и я надеюсь записать свое собственное обучение.

Эта статья предназначена для обменов обучения, а нарушение должно быть удалено.
Недоступно для коммерческих целей, укажите источник.

Сообщение об ошибке

• Выполнить резервное копирование команды pg_dump, подскажитеcache lookup failed for type… ошибка.

2018-03-08 00:19:14 4285: Start of engine-backup mode backup scope all file /root/ovirt-engine.bak
2018-03-08 00:19:14 4285: Backing up:
2018-03-08 00:19:14 4285: Generating pgpass
2018-03-08 00:19:15 4285: Creating temp folder /tmp/engine-backup.Z8RvsbYGGl/tar
2018-03-08 00:19:15 4285: - Files
2018-03-08 00:19:15 4285: Backing up files to /tmp/engine-backup.Z8RvsbYGGl/tar/files
2018-03-08 00:19:15 4285: - Engine database 'engine'
2018-03-08 00:19:15 4285: Backing up database to /tmp/engine-backup.Z8RvsbYGGl/tar/db/engine_backup.db
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  cache lookup failed for type 222222
pg_dump: The command was: SELECT proretset, prosrc, probin, pg_catalog.pg_get_function_arguments(oid) AS funcargs, pg_catalog.pg_get_function_identity_arguments(oid) AS funciargs, pg_catalog.pg_get_function_result(oid) AS funcresult, proiswindow, provolatile, proisstrict, prosecdef, proconfig, procost, prorows, (SELECT lanname FROM pg_catalog.pg_language WHERE oid = prolang) AS lanname FROM pg_catalog.pg_proc WHERE oid = '237534'::pg_catalog.oid
2018-03-08 00:19:16 4285: FATAL: Database engine backup failed

Анализ ошибок

• Согласно оперативной информации о запросах онлайн-запроса, она, вероятно, поймет причину ошибки. Справочная информация выглядит следующим образом.

1. https://www.postgresql.org/message-id/AANLkTik0Nfyw%[email protected]
2. http://www.postgresql-archive.org/Cache-lookup-failure-for-index-during-pg-dump-td2125326.html

• Согласно приглашенной информации в вышеупомянутом журнале, вы можете определить 222222 этого идентификационного номера.pg_type Невозможно найти его в таблице.

# select * from pg_type where oid = '222222';
 typname | typnamespace | typowner | typlen | typbyval | typtype | typcategory | typispreferred | typisdefined | typdelim | typrelid | typelem | typarray | typinput | typoutput | typreceive | typsend | typmodin | typmodout | typanalyze 
| typalign | typstorage | typnotnull | typbasetype | typtypmod | typndims | typdefaultbin | typdefault 
---------+--------------+----------+--------+----------+---------+-------------+----------------+--------------+----------+----------+---------+----------+----------+-----------+------------+---------+----------+-----------+------------
+----------+------------+------------+-------------+-----------+----------+---------------+------------
(0 rows)

• Анализироватьpg_proc Таблица структуры. Проверятьpg_proc В таблицеpg_type.oid Ссылка, связанные с полями.

# select provariadic,prorettype,proallargtypes,proargtypes from pg_proc where provariadic = '222222' or prorettype = '222222' or proallargtypes @> '{222222}' or proargtypes @> '222222';
 provariadic | prorettype | proallargtypes | proargtypes  
-------------+------------+----------------+--------------
           0 |     222222 |                | 2950 2950 16
(1 row)

• Запрошенныйprorettype Идентификатор 222222 используется в поле.

решение

• Будетpg_proc Таблицаproname Поля также выводятся, подтверждают имя функции.

# select proname,provariadic,prorettype,proallargtypes,proargtypes from pg_proc where provariadic = '222222' or prorettype = '222222' or proallargtypes @> '{222222}' or proargtypes @> '222222';
           proname            | provariadic | prorettype | proallargtypes | proargtypes  
------------------------------+-------------+------------+----------------+--------------
 getuserpermissionsbyentityid |           0 |     222222 |                | 2950 2950 16
(1 row)

• Найдите эту функцию в базе данных в соответствии с именем функции GetUserPermissionnentityId.

  • Просмотр Тип возврата этой функции — permissions_view.

• Вpg_type Независимо от того, является ли именем типов запроса в типе Permissions_View.

# select oid from pg_type where typname = 'permissions_view';
  oid   
--------
 236728
(1 row)

• Запрос Тип Permissions_Viewoid № 236728. (Если вы не запрашиваете, вам нужно вручную вставить эти данные, затем проверьте OID).

• Модифицироватьpg_proc В таблицеprorettype Ссылка только на поля составляет 236728.

# update pg_proc set prorettype = '236728' where proname = 'getuserpermissionsbyentityid';
UPDATE 1

• Резервное копирование снова успешно.

2018-03-08 00:49:49 4677: Start of engine-backup mode backup scope all file /root/ovirt-engine.bak
2018-03-08 00:49:49 4677: Backing up:
2018-03-08 00:49:49 4677: Generating pgpass
2018-03-08 00:49:49 4677: Creating temp folder /tmp/engine-backup.4n8mAdmak4/tar
2018-03-08 00:49:49 4677: - Files
2018-03-08 00:49:49 4677: Backing up files to /tmp/engine-backup.4n8mAdmak4/tar/files
2018-03-08 00:49:50 4677: - Engine database 'engine'
2018-03-08 00:49:50 4677: Backing up database to /tmp/engine-backup.4n8mAdmak4/tar/db/engine_backup.db
2018-03-08 00:49:51 4677: Creating md5sum at /tmp/engine-backup.4n8mAdmak4/tar/md5sum
2018-03-08 00:49:53 4677: Packing into file '/root/ovirt-engine.bak'
2018-03-08 00:49:53 4677: Creating tarball /root/ovirt-engine.bak
2018-03-08 00:50:06 4677: Done.