Error cache lookup failed for function 0

XX000 (cache lookup failed for function) not covered by autosave=conservative #1786

Describe the issue
In some rare cases database could throw XX000 error with message «cache lookup failed for function «. Reverting to savepoint before query and re-executing query fixes the problem.
According to the autosave parameter description, we expected jdbc driver to fix this error with autosave=conservative but it does not.

Driver Version?
42.2.12
42.2.13-20200331.194247-1

Java Version?
jdk-8.0.252.09-hotspot

OS Version?
Window 7 x64

PostgreSQL Version?
reproduced for: PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
cannot reproduce for: PostgreSQL 12.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

To Reproduce
Save as «TestXX000.java», modify connection string in getConn() function, compile and run in the presence of jdbc driver:

Provided functions and query are the minimal reproduced example.

Expected behaviour
JDBC driver handles «ERROR: cache lookup failed for function » itself, no savepoint required.
The output expected to be:

Actual behaviour
Program must handle error itself, one execution result is missing, actual output is:

May be a postgresql problem, but seems not affected latest postgresql version.

The text was updated successfully, but these errors were encountered:

Источник

MS Sql -> Postgres

Есть 2 базы. БУХ 3.0 и УПП 1.3
Перенос проводил через выгрузку загрузку .DT с предварительным ТИИ .
Бух 3.0 нормально перенеслась из MS SQL в Postgres . Бэкапится и работает.

УПП 1.3: При проведении документа ОШИБКА СУБД cache lookup failed for function 0
Поиски привели к необходимости сделать Дамп/Бэкап
При попытке сделать Бэкап, ошибка:
pg_dump: saving standard_conforming_strings = off

pg_dump: saving search_path =

pg_dump: saving database definition

pg_dump: [archiver (db)] query failed: ERROR: invalid memory alloc request size 1191164729

pg_dump: [archiver (db)] query was: FETCH 100 FROM _pg_dump_cursor

(1)
Доброго дня.
Аналогично пытался перенести упп на postgres. База около 30 гиг размером.
PG с сайта 1с последний. Предприятие оттуда же, 8.3.15.
Получил такую же ошибку.
Дамп делал, не помогло.
Так же пробовал делать тестирование и исправление. Все проходит успешно, если не ставить галку «реструктуризация таблиц». На этом падает.
Но эффект от этих действий нулевой.
Пришлось вернуться к mssql.

Осталось попробовать только pg_dumpall.

Тоже перенес на Postgres
8.3.16.1148 конфиг бухгалтерия 1.2
база маленькая, места навалом, проверка и рестурктуризация на ура
А вот отмена проведения произвольного документа (не всех) вываливает эту ошибку

Нагуглил что это связано с шаманствами преобразования строк mvarchar — но как исправить не нашел

Бухгалтерия 2.0
Очередное обновление потребовало обновление платформы. Заодно, решили обновить PostgreSQL.
И так, платформа 8.3.16.1148 и PostgreSQL 11.5-12
В итоге, на многих операциях (проведение документа, пометка на удаление и тп) — ОШИБКА СУБД cache lookup failed for function 0

Пришлось понизить версию PostgreSQL до 10.10-4

Поимел такую же ошибку (ОШИБКА СУБД cache lookup failed for function 0) на УПП 1.3, релиз 1.3.134.1, платформа 8.3.15.1489, постгрес 11.5-12.1С(х64).
База небольшая, dt 1.3гб. *.dt выгружается, на файловой базе ошибки нет. Конфигурация почти типовая, но без замочка.

Использовал различные танцы с бубном навроде: майнтенанс базы pgAdmin-ом, ТИИ, вкуривание логов постгре, изменение регистра бухгалтерии туда-сюда (для инициирования реструктуризации и пересоздания таблиц в постгре), удаления проблемной таблицы средствами постгре. Логи постгре говорят, что проблема в таблице итогов регистра бухгалтерии по субконто _AccRgAT21653. Но что с этой таблицей ни делай, ошибка возвращается.

РЕШЕНИЕ:
поставил в конфигурации режим совместимости «Версия 8.3.9». Да, появляются артефакты, вроде дублирования имен картинок (которые в 8.3.9 стали системными) и некоторых функций общего модуля ОбщийМодуль.ИнтеграцияЕГАИСУТКлиентСерверГлобальный.Модуль(8,9)>: Процедура или функция с указанным именем уже определена (СтрНайти) — нужно переименовывать функции.
Но проблема с cache lookup failed ушла. Прогонял разные документы — пока все ровно. Буду наблюдать далее.

BTW: УПП в дефолтовом режиме совместимости весьма плохо дружит с постгре в плане производительности. на большой базе с количеством пользователей около 100 было невозможно работать, пока не поднял режим совместимости. После этого платформа 1с начинает генерировать адекватные запросы в постгре.

Источник

Describe the issue
In some rare cases database could throw XX000 error with message «cache lookup failed for function «. Reverting to savepoint before query and re-executing query fixes the problem.
According to the autosave parameter description, we expected jdbc driver to fix this error with autosave=conservative but it does not.

Driver Version?
42.2.12
42.2.13-20200331.194247-1

Java Version?
jdk-8.0.252.09-hotspot

OS Version?
Window 7 x64

PostgreSQL Version?
reproduced for: PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
cannot reproduce for: PostgreSQL 12.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

To Reproduce
Save as «TestXX000.java», modify connection string in getConn() function, compile and run in the presence of jdbc driver:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Savepoint;
import java.sql.Statement;
import java.util.Locale;
import java.util.Properties;

public class TestXX000 {

    //@fmt:off
    private static final String FUNC0 = 
            "create or replace function public.textXX000_internal(t in text, flag in boolean default true) returns text as $$n" +
            "select case when flag then t else (select nspname::text from pg_catalog.pg_namespace where nspname = 'public') endn" + 
            "$$ language sql stable called on null input;";
    private static final String FUNC = 
            "BEGIN;n" +
            "DROP SCHEMA IF EXISTS textXX000 CASCADE;n" + 
            "CREATE SCHEMA textXX000;n" +
            "GRANT USAGE ON SCHEMA textXX000 TO public;n" + 
            "ALTER DEFAULT PRIVILEGES IN SCHEMA textXX000 GRANT EXECUTE ON FUNCTIONS TO public;n" + 
            "SET SEARCH_PATH TO testXX000;rn" + 
            "create or replace function textXX000.testXX000(t in text, i integer) returns text as $$n" +
            "beginn" + 
            "  return t || i;n" + 
            "end;n" + 
            "$$ language plpgsql stable returns null on null input;" + 
            "END;";
    private static final String FUNCOIDS =
            "SELECT n as func, n::regproc::oid as idrn" + 
            "  from unnest('{public.textXX000_internal,textXX000.testXX000}'::text[]) n";
    private static final String SQL = 
            "select textXX000.testXX000(public.textXX000_internal(?), ?);";
    //@fmt:on

    public static void main(String[] args) throws SQLException, InterruptedException {
        Locale.setDefault(Locale.ENGLISH);
        Thread thr = new Thread(TestXX000::threadFunc);
        thr.start();
        Thread.sleep(1000);

        try (Connection conn = getConn();
                // PreparedStatement ps2 = conn.prepareStatement("DEALLOCATE ALL");
                PreparedStatement ps = conn.prepareStatement(SQL)) {
            conn.setAutoCommit(false);
            for (int i = 0; i < 3; ++i) {
                ps.setString(1, "iteration # ");
                ps.setInt(2, i);

                // ps2.execute();
                Savepoint sp = conn.setSavepoint("123");
                try (ResultSet rs = ps.executeQuery()) {
                    boolean b = rs.next();
                    System.out.println(
                            "ok: " + b + (b ? " " + ps.getMetaData().getColumnName(1) + " = " + rs.getString(1) : ""));
                } catch (SQLException e) {
                    System.err.println(e.getSQLState() + " " + e.getMessage());
                    if ("XX000".equals(e.getSQLState()))
                        conn.rollback(sp);
                    else
                        throw e;
                } finally {
                    conn.releaseSavepoint(sp);
                }
                Thread.sleep(1000);
            }
        } finally {
            thr.interrupt();
            thr.join();
        }
    }

    private static void threadFunc() {
        try (Connection conn = getConn();
                Statement st = conn.createStatement();
                PreparedStatement ps = conn.prepareStatement(FUNCOIDS)) {
            conn.setAutoCommit(true);
            st.execute(FUNC0);
            for (int i = 2; i > 0; --i) {
                st.execute(FUNC);
                try (ResultSet rs = ps.executeQuery()) {
                    StringBuilder b = new StringBuilder();
                    while (rs.next()) {
                        if (b.length() > 0)
                            b.append(",");
                        b.append(rs.getString("func")).append("=").append(rs.getLong("id"));
                    }
                    System.out.println("recompiled: " + b);
                }
                Thread.sleep(750);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } catch (SQLException e) {
            System.out.println(e.getSQLState());
            throw new RuntimeException(e.getMessage(), e);
        }
    }

    private static Connection getConn() throws SQLException {
        Properties props = new Properties();
        props.setProperty("user", "postgres");
        props.setProperty("password", "postgres");
        props.setProperty("loggerLevel", "TRACE");
        props.setProperty("loggerFile", "pgjdbc-trace.log");
        props.put("autosave", "conservative");
        // props.put("prepareThreshold", 0);

        return DriverManager.getConnection("jdbc:postgresql://IP:5432/DATABASE", props);
    }

}

Provided functions and query are the minimal reproduced example.

Expected behaviour
JDBC driver handles «ERROR: cache lookup failed for function <…>» itself, no savepoint required.
The output expected to be:

recompiled: public.textXX000_internal=208173185,textXX000.testXX000=208182048
ok: true testxx000 = iteration # 0
recompiled: public.textXX000_internal=208173185,textXX000.testXX000=208182051
ok: true testxx000 = iteration # 1
ok: true testxx000 = iteration # 2

Actual behaviour
Program must handle error itself, one execution result is missing, actual output is:

recompiled: public.textXX000_internal=208173185,textXX000.testXX000=208182048
ok: true testxx000 = iteration # 0
recompiled: public.textXX000_internal=208173185,textXX000.testXX000=208182051
XX000 ERROR: cache lookup failed for function 208182048
  Location: File: lsyscache.c, Routine: get_func_cost, Line: 1616
  Server SQLState: XX000
ok: true testxx000 = iteration # 2

May be a postgresql problem, but seems not affected latest postgresql version.

Logs
pgjdbc-trace.log.zip

Now we want to use pgsql_fdw to select a table of remote postgresql database，When we
select the table in a session it is okey ,but when we use the foreign table in a funciton
it turns out «ERROR: cache lookup failed for type 0» ， anybody knows it ,thanks !

--1 base informaiton

skytf=> d ft_test;
       Foreign table "skytf.ft_test"
 Column |         Type          | Modifiers 
--------+-----------------------+-----------
 id     | integer               | 
 name   | character varying(32) | 
Server: pgsql_srv


skytf=> des+ pgsql_srv
                                                List of foreign servers
   Name    | Owner | Foreign-data wrapper | Access privileges | Type | Version |                Options                 
-----------+-------+----------------------+-------------------+------+---------+----------------------------------------
 pgsql_srv | skytf | pgsql_fdw            |                   |      |         | {host=127.0.0.1,port=1923,dbname=mydb}
(1 row)

--2 destination table 
mydb=> d test
             Table "mydb.test"
 Column |         Type          | Modifiers 
--------+-----------------------+-----------
 id     | integer               | 
 name   | character varying(32) | 
Indexes:
    "idx_test_1" btree (id)

--3 function
 CREATE or replace FUNCTION  func_sync_bill() RETURNS INTEGER  AS $$
    BEGIN

     begin
      insert into test_tf (id,name) select id,name from ft_test;
      return 1;
     end; 
    END;
  $$ LANGUAGE 'plpgsql';




--4 it works in a session
skytf=> create table test_tf(id integer,name varchar(32));
CREATE TABLE

skytf=> insert into test_tf select * from ft_test;
INSERT 0 1990000


--5 function call error
skytf=> truncate table test_tf;
TRUNCATE TABLE

skytf=> select func_sync_bill();
ERROR:  cache lookup failed for type 0
CONTEXT:  SQL statement "insert into test_tf (id,name) select id,name from ft_test"
PL/pgSQL function "func_sync_bill" line 5 at SQL statement

when I call the function func_sync_bill() which will select a foreign table , it turns out the error.
Is this a bug of pgsql_fdw?

—verbose meeage

    skytf=> set VERBOSITY verbose
    skytf=> select func_sync_bill();
    ERROR:  XX000: cache lookup failed for type 0
    CONTEXT:  SQL statement "insert into test_tf (id,name) select id,name from ft_test"
    PL/pgSQL function "func_sync_bill" line 5 at SQL statement

LOCATION:  getTypeOutputInfo, lsyscache.c:2441

Howdy,

I ran into this error on 8.2 a while ago, and just figured out what
was causing it. Here’s a quick example on 8.2:

BEGIN;

— Compare name[]s more or less like 8.3 does.
CREATE OR REPLACE FUNCTION namearray_text(name[])
RETURNS TEXT AS ‘SELECT textin(array_out($1));’
LANGUAGE sql IMMUTABLE STRICT;

CREATE CAST (name[] AS text) WITH FUNCTION namearray_text(name[]) AS
IMPLICIT;

CREATE OR REPLACE FUNCTION namearray_eq( name[], name[] )
RETURNS bool
AS ‘SELECT $1::text = $2::text;’
LANGUAGE sql IMMUTABLE STRICT;

CREATE OPERATOR = (
LEFTARG = name[],
RIGHTARG = name[],
NEGATOR = <>,
PROCEDURE = namearray_eq
);

SELECT ‘{foo}’::name[] <> ‘{bar}’::name[];

ROLLBACK;

If you comment out the NEGATOR line, the error is changed to the more
useful

ERROR: operator is not unique: name[] <> name[]

I’m assuming that, if you did this for 8.3 (which has name[]
comparison operators in core, so it’d have to be an operator with some
other type), you’d get the same useless error.

Ideally, in the situation where a NEGATOR (or commutator, too?) is
specified but has not actually been defined, you’d get an error such as:

ERROR: operator not defined: name[] <> name[]

Thanks,

David

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

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