BUG #15553: "ERROR: cache lookup failed for type 2" with a function the first time it run.

Started by PG Bug reporting formover 7 years ago5 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 15553
Logged by: Jean-Marc Lessard
Email address: jm.lessard@contactft.com
PostgreSQL version: 11.1
Operating system: Windows 2012 R2
Description:

I compiled posgreSQL 11 for windows with MSYS2 64bit (includes mingw64)
following the procedure outline
in
https://www.cybertec-postgresql.com/en/building-postgresql-with-msys2-and-mingw-under-windows/

select version();
version
-------------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 11.1 on x86_64-w64-mingw32, compiled by
x86_64-w64-mingw32-gcc.exe (Rev1, Built by MSYS2 project) 8.2.1 20181207,
64-bit

I got an "ERROR: cache lookup failed for type 2" when a function is run for
the first time in a session.
The function run successfully the second time.
Please find the test case as follow:

Setup:
CREATE SCHEMA IF NOT EXISTS test;
set search_path=test,public;
SELECT current_schema() \gset

CREATE TABLE IF NOT EXISTS dis_con (
nspname NAME NOT NULL,
relname NAME NOT NULL,
conname NAME NOT NULL,
contype NAME NOT NULL, --c =
check constraint, f = foreign key constraint, p = primary key constraint, u
= unique constraint
condef TEXT NOT NULL,
state VARCHAR(8) NOT NULL, --staged
(constraint is queued to be dropped) or dropped
drop_by NAME NOT NULL,
drop_tim TIMESTAMPTZ(0) DEFAULT
CURRENT_TIMESTAMP NOT NULL,
CONSTRAINT discon2_pk PRIMARY KEY (nspname, relname, conname)
);

CREATE OR REPLACE FUNCTION disable_constraints2(contype_p CHAR)
RETURNS TABLE(owner_schema TEXT, constraint_name TEXT,
current_constraint_def TEXT, dropped_constraint_def TEXT)
AS $BODY$
DECLARE
rowcnt INTEGER := 0;
con RECORD;
BEGIN
--Stage or queue for dropping (update the constraint state) the
constraints that exist which are in the disable_contraints table from a
previous drop with the same definition (defininition checked above).
UPDATE dis_con d SET state = 'staged', drop_by = session_user, drop_tim=
CURRENT_TIMESTAMP
WHERE EXISTS (SELECT 1 FROM pg_constraint
JOIN pg_class ON conrelid=pg_class.oid
JOIN pg_namespace ON
pg_namespace.oid=pg_class.relnamespace
WHERE pg_namespace.nspname = current_schema()
AND pg_constraint.contype = contype_p
AND pg_namespace.nspname=d.nspname AND
pg_class.relname=d.relname AND pg_constraint.conname=d.conname AND
pg_constraint.contype=d.contype AND
pg_get_constraintdef(pg_constraint.oid)=d.condef);
IF FOUND THEN
GET DIAGNOSTICS rowcnt = ROW_COUNT;
RAISE INFO '% constraint(s) are re-staged for dropping.',
rowcnt::TEXT;
END IF;
GET DIAGNOSTICS rowcnt = ROW_COUNT;

--Staging constraints that will be dropped and saving the constraint
definition.
INSERT INTO dis_con (SELECT nspname, relname, conname, contype,
pg_get_constraintdef(pg_constraint.oid), 'staged', session_user,
CURRENT_TIMESTAMP
FROM pg_constraint
JOIN pg_class ON
conrelid=pg_class.oid
JOIN pg_namespace ON
pg_namespace.oid=pg_class.relnamespace
WHERE
pg_namespace.nspname = current_schema()
AND
pg_constraint.contype = contype_p
AND NOT EXISTS (SELECT
1 FROM dis_con d WHERE pg_namespace.nspname=d.nspname AND
pg_class.relname=d.relname AND pg_constraint.conname=d.conname AND
pg_constraint.contype=d.contype));
IF FOUND THEN
GET DIAGNOSTICS rowcnt = ROW_COUNT;
RAISE INFO '% constraint(s) are staged for dropping.', rowcnt::TEXT;
END IF;

--Dropping the staged constraints
rowcnt := 0;
FOR con IN SELECT nspname, relname, conname FROM dis_con WHERE
nspname=current_schema() AND contype=contype_p AND state='staged' LOOP
EXECUTE 'ALTER TABLE
'||quote_ident(con.nspname)||'.'||quote_ident(con.relname)||' DROP
CONSTRAINT '||quote_ident(con.conname);
UPDATE dis_con SET state='dropped', drop_by = session_user, drop_tim
= CURRENT_TIMESTAMP WHERE nspname=con.nspname AND relname=con.relname AND
conname=con.conname AND contype=contype_p;
RAISE INFO '% constraint dropped.', con.conname;
rowcnt := rowcnt + 1;
END LOOP;

RETURN QUERY SELECT current_schema()::TEXT, rowcnt::TEXT||'
'||UPPER(contype_p)||'K constraint(s) were
disabled.',NULL::TEXT,NULL::TEXT;

END
$BODY$ LANGUAGE plpgsql
SET search_path = :current_schema, pg_catalog;

Test Case
1. \q and start a new psql session

--Do not forget to set the search path because the function will drop the
constraints in your current_schema. You can recreate them with the select
from dis_con table.
2. set search_path=test,public;
SELECT disable_constraints2('f');
ERROR: cache lookup failed for type 2
CONTEXT: SQL statement "UPDATE dis_con d SET state = 'staged', drop_by =
session_user, drop_tim= CURRENT_TIMESTAMP
...
PL/pgSQL function disable_constraints2(character) line 7 at SQL statement

3. Run the function a second time
SELECT disable_constraints2('f');
disable_constraints2
----------------------------------------------
(test,"0 FK constraint(s) were disabled.",,)

--just in case
SELECT 'ALTER TABLE '||nspname||'.'||relname||' ADD CONSTRAINT '||conname||'
'||condef||';' FROM dis_con;

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: PG Bug reporting form (#1)
Re: BUG #15553: "ERROR: cache lookup failed for type 2" with a function the first time it run.

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:

I got an "ERROR: cache lookup failed for type 2" when a function is run for
the first time in a session.

That certainly looks like a bug, but I can't replicate it from the
given instructions.

The function seems to expect that the current schema contains some
foreign key constraints, which it doesn't when I just follow your
script exactly. However, even if I add a few more tables with
foreign-key relationships, all seems well.

Please provide a complete script that will reproduce the problem
starting from an empty database. Also, have you got any extensions
loaded, or any unusual configuration settings?

regards, tom lane

#3Jean-Marc Lessard
Jean-Marc.Lessard@ultra-ft.com
In reply to: Tom Lane (#2)
RE: BUG #15553: "ERROR: cache lookup failed for type 2" with a function the first time it run.

I think I got it. Looks like related to pgaudit.

I did an initdb and run the test case without issue

As soon as l add pgaudit and create the extension, the error is raised
You do not need any FK in the test schema to reproduce the problem.

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'all'
pgaudit.log_catalog = on
pgaudit.log_parameter = on

pgaudit 1.3 is installed (the PG11 compatible version)

select * from pg_extension;
extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
--------------------+----------+--------------+----------------+------------+-----------+--------------
plpgsql | 10 | 11 | f | 1.0 | (NULL) | (NULL)
adminpack | 10 | 11 | f | 2.0 | (NULL) | (NULL)
lo | 10 | 16394 | t | 1.1 | (NULL) | (NULL)
postgres_fdw | 10 | 16394 | t | 1.0 | (NULL) | (NULL)
pg_stat_statements | 10 | 16394 | t | 1.6 | (NULL) | (NULL)
pgrowlocks | 10 | 16394 | t | 1.2 | (NULL) | (NULL)
pgstattuple | 10 | 16394 | t | 1.5 | (NULL) | (NULL)
pg_freespacemap | 10 | 16394 | t | 1.2 | (NULL) | (NULL)
pgaudit | 10 | 16432 | t | 1.3 | (NULL) | (NULL)
(9 rows)

You should now be able to reproduce it.

Regards, JML

Jean-Marc Lessard
Administrateur de base de données / Database Administrator
Ultra Electronics Forensic Technology Inc.
T +1 514 489 4247 x4164
www.ultra-forensictechnology.com<http://www.ultra-forensictechnology.com&gt;

-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Friday, December 14, 2018 3:27 PM
To: Jean-Marc Lessard <Jean-Marc.Lessard@ultra-ft.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15553: "ERROR: cache lookup failed for type 2" with a function the first time it run.

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:

I got an "ERROR: cache lookup failed for type 2" when a function is
run for the first time in a session.

That certainly looks like a bug, but I can't replicate it from the given instructions.

The function seems to expect that the current schema contains some foreign key constraints, which it doesn't when I just follow your script exactly. However, even if I add a few more tables with foreign-key relationships, all seems well.

Please provide a complete script that will reproduce the problem starting from an empty database. Also, have you got any extensions loaded, or any unusual configuration settings?

regards, tom lane

#4Jean-Marc Lessard
Jean-Marc.Lessard@ultra-ft.com
In reply to: Jean-Marc Lessard (#3)
RE: BUG #15553: "ERROR: cache lookup failed for type 2" with a function the first time it run.

Hi Tom, were you able to reproduce the issue.

Or would you rather prefer that I submit the issue to the pgaudit team.

Regards, JML

Jean-Marc Lessard
Administrateur de base de donn?es / Database Administrator
Ultra Electronics Forensic Technology Inc.
T +1 514 489 4247 x4164
www.ultra-forensictechnology.com<http://www.ultra-forensictechnology.com&gt;

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jean-Marc Lessard (#4)
Re: BUG #15553: "ERROR: cache lookup failed for type 2" with a function the first time it run.

Jean-Marc Lessard <Jean-Marc.Lessard@ultra-ft.com> writes:

Hi Tom, were you able to reproduce the issue.

I didn't try; pgaudit is not my thing.

Or would you rather prefer that I submit the issue to the pgaudit team.

Please report to them.

regards, tom lane