Error encountered while inserting index tuple in pg_type_typname_nsp_index during CREATE TABLE secrets statement

Satya T. · 2026-03-10T02:34:07.847Z

2026-03-10T02:12:14.096761825Z CONTEXT: while inserting index tuple (57,38) in relation "pg_type_typname_nsp_index" 2026-03-10T02:12:14.096765310Z [SQL: 2026-03-10T02:12:14.096769055Z CREATE TABLE secrets ( 2026-03-10T02:12:14.096772776Z key VARCHAR NOT NULL, 2026-03-10T02:12:14.096776412Z value BYTEA NOT NULL, 2026-03-10T02:12:14.096779999Z user_id BIGINT, 2026-03-10T02:12:14.096783530Z updated_at TIMESTAMP WITH TIME ZONE DEFAULT now() NOT NULL, 2026-03-10T02:12:14.096787089Z CONSTRAINT pk_secrets PRIMARY KEY (key), 2026-03-10T02:12:14.096790849Z CONSTRAINT fk_secrets_user_id_users FOREIGN KEY(user_id) REFERENCES users (id) ON DELETE SET NULL 2026-03-10T02:12:14.096794530Z ) 2026-03-10T02:12:14.096798108Z 2026-03-10T02:12:14.096801851Z ]

15 comments

· Sorted by Oldest

RunLLM
APP
·
·
Your error is likely due to a data type mismatch between the secrets.user_id column (BIGINT) and users.id (INTEGER/serial) in PostgreSQL. This prevents the foreign key constraint from being created, as PostgreSQL requires both columns to have the exact same type for referential integrity. This is a known schema issue in Phoenix and will cause migration or table creation failures until resolved by aligning the types (<https://github.com/Arize-ai/phoenix/pull/9693|details>, <https://github.com/Arize-ai/phoenix/pull/9393|details>). Would you like more detail on how to resolve or work around this schema mismatch? Sources: - <https://github.com/Arize-ai/phoenix/pull/9393|https://github.com/Arize-ai/phoenix/pull/9393> - <https://github.com/Arize-ai/phoenix/pull/9693|details>
💡 Hint: Mention RunLLM in the thread for followups.
Satya T.
·
·
but this work with ole version of phoenix: 12.1 version

Roger Y.

Hi Satya. Can you run these diagnostic queries against your Phoenix database and share the results?

-- 1. Does the secrets table actually exist?
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_name = 'secrets';

-- 2. Is there an orphaned type entry with no backing table?
SELECT typname, typrelid
FROM pg_type
WHERE typname = 'secrets'
  AND typtype = 'c';

-- 3. What is the current Alembic migration state?
SELECT * FROM alembic_version;

-- 4. Are there other orphaned types from the same migration?
SELECT typname, typrelid
FROM pg_type
WHERE typname IN (
  'secrets', 'evaluators', 'llm_evaluators', 'code_evaluators',
  'dataset_evaluators', 'generative_model_custom_providers'
)
  AND typtype = 'c'
  AND typrelid = 0;

Satya T.
·
·
Hi Roger, Thanks for response , all the queries gave me empty results except for this (SELECT * FROM alembic_version;)
Satya T.
·
·
is there any database level upgrade need to be done when we migrate from docker file 12.x version to 13.X version ?
Roger Y.
·
·
each major version bump contains new database migrations. so the errors looks like it’s encountering an issue with the new secrets table
Satya T.
·
·
ok
Roger Y.
·
·
what’s the value you got from (SELECT * FROM alembic_version;
Satya T.
·
·
version number
Roger Y.
·
·
are you using a schema? what do you get when you run this?
SHOW search_path; SELECT current_schema();
Roger Y.
·
·
version number
can you give me the specific value?
Satya T.
·
·
deb2c81c0bb2

Roger Y.

can you run this?

SHOW search_path;
SELECT current_schema();
SELECT nspname FROM pg_namespace WHERE nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast');

Satya T.
·
·
its has schemas

Roger Y.

Thanks. A few follow-ups: 1. What is your `PHOENIX_SQL_DATABASE_SCHEMA` env var set to? (Or what schemas did you see from that last query?) 2. Run these queries — they’re broader than the first set and join with `pg_namespace` to show which schema any matches live in:

-- First, set your search_path to match Phoenix's config
-- Replace <your_schema> with your PHOENIX_SQL_DATABASE_SCHEMA value
SET search_path TO <your_schema>;

-- 1. Look for ANY type named 'secrets' (no typtype filter this time)
SELECT t.typname, t.typrelid, t.typtype, n.nspname
FROM pg_type t
JOIN pg_namespace n ON t.typnamespace = n.oid
WHERE t.typname = 'secrets';

-- 2. Check for tables named 'secrets' in ALL schemas
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_name = 'secrets';

-- 3. Show your current search_path to confirm
SHOW search_path;

3. If query 1 returns a result, the fix is:

SET search_path TO <your_schema>;
DROP TYPE IF EXISTS secrets CASCADE;

4. If query 1 still returns empty, this is likely index corruption. Try:

REINDEX INDEX pg_catalog.pg_type_typname_nsp_index;

Error encountered while inserting index tuple in pg_type_typname_nsp_index during CREATE TABLE secrets statement | Arize AI Community

RunLLM
APP
·
·
Your error is likely due to a data type mismatch between the secrets.user_id column (BIGINT) and users.id (INTEGER/serial) in PostgreSQL. This prevents the foreign key constraint from being created, as PostgreSQL requires both columns to have the exact same type for referential integrity. This is a known schema issue in Phoenix and will cause migration or table creation failures until resolved by aligning the types (<https://github.com/Arize-ai/phoenix/pull/9693|details>, <https://github.com/Arize-ai/phoenix/pull/9393|details>). Would you like more detail on how to resolve or work around this schema mismatch? Sources: - <https://github.com/Arize-ai/phoenix/pull/9393|https://github.com/Arize-ai/phoenix/pull/9393> - <https://github.com/Arize-ai/phoenix/pull/9693|details>
💡 Hint: Mention RunLLM in the thread for followups.
Satya T.
·
·
but this work with ole version of phoenix: 12.1 version

Roger Y.

Hi Satya. Can you run these diagnostic queries against your Phoenix database and share the results?

-- 1. Does the secrets table actually exist?
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_name = 'secrets';

-- 2. Is there an orphaned type entry with no backing table?
SELECT typname, typrelid
FROM pg_type
WHERE typname = 'secrets'
  AND typtype = 'c';

-- 3. What is the current Alembic migration state?
SELECT * FROM alembic_version;

-- 4. Are there other orphaned types from the same migration?
SELECT typname, typrelid
FROM pg_type
WHERE typname IN (
  'secrets', 'evaluators', 'llm_evaluators', 'code_evaluators',
  'dataset_evaluators', 'generative_model_custom_providers'
)
  AND typtype = 'c'
  AND typrelid = 0;

Satya T.
·
·
Hi Roger, Thanks for response , all the queries gave me empty results except for this (SELECT * FROM alembic_version;)
Satya T.
·
·
is there any database level upgrade need to be done when we migrate from docker file 12.x version to 13.X version ?
Roger Y.
·
·
each major version bump contains new database migrations. so the errors looks like it’s encountering an issue with the new secrets table
Satya T.
·
·
ok
Roger Y.
·
·
what’s the value you got from (SELECT * FROM alembic_version;
Satya T.
·
·
version number
Roger Y.
·
·
are you using a schema? what do you get when you run this?
SHOW search_path; SELECT current_schema();
Roger Y.
·
·
version number
can you give me the specific value?
Satya T.
·
·
deb2c81c0bb2

Roger Y.

can you run this?

SHOW search_path;
SELECT current_schema();
SELECT nspname FROM pg_namespace WHERE nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast');

Satya T.
·
·
its has schemas

Roger Y.

-- First, set your search_path to match Phoenix's config
-- Replace <your_schema> with your PHOENIX_SQL_DATABASE_SCHEMA value
SET search_path TO <your_schema>;

-- 1. Look for ANY type named 'secrets' (no typtype filter this time)
SELECT t.typname, t.typrelid, t.typtype, n.nspname
FROM pg_type t
JOIN pg_namespace n ON t.typnamespace = n.oid
WHERE t.typname = 'secrets';

-- 2. Check for tables named 'secrets' in ALL schemas
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_name = 'secrets';

-- 3. Show your current search_path to confirm
SHOW search_path;

3. If query 1 returns a result, the fix is:

SET search_path TO <your_schema>;
DROP TYPE IF EXISTS secrets CASCADE;

4. If query 1 still returns empty, this is likely index corruption. Try:

REINDEX INDEX pg_catalog.pg_type_typname_nsp_index;