The fdw_no_schemas error (SQLSTATE HV00P) means the foreign data wrapper could not find any schemas on the remote server that match the import or query request.
fdw_no_schemas (SQLSTATE HV00P) occurs when a PostgreSQL foreign data wrapper cannot detect any schemas on the target server. Verify the remote connection, schema visibility, and IMPORT FOREIGN SCHEMA filters. Creating or granting access to the needed schemas, then rerunning the command, resolves the issue.
fdw_no_schemas
PostgreSQL raises fdw_no_schemas when a foreign data wrapper (FDW) call expects at least one schema on the remote server but none are returned. The SQLSTATE is HV00P, and you usually see it while running IMPORT FOREIGN SCHEMA, REFRESH FOREIGN TABLE, or executing a query that triggers a schema scan.
The server believes the connection is valid, yet the remote side replied with an empty schema list or the user lacks permission to see schemas.
Fixing the visibility or filter criteria removes the error.
The FDW fails to list schemas if the remote user lacks USAGE privileges, the connection string points to a database without schemas, or the IMPORT FOREIGN SCHEMA statement filters everything out. Misconfigured options such as schema_pattern or only_import can also result in zero matches.
Some FDWs, like postgres_fdw and mysql_fdw, check pg_namespace or INFORMATION_SCHEMA on the remote.
Corrupted catalogs, dropped databases, or firewall-blocked metadata queries will therefore surface as fdw_no_schemas.
First confirm the remote database actually contains schemas. Log in with psql or the native client and list schemas. Grant USAGE on each schema to the FDW user. Review import filters so at least one schema matches. Recreate missing schemas if they were dropped.
If using postgres_fdw, set the option fetch_size or extensions false only after validating schemas.
For mysql_fdw, ensure the database name in OPTIONS (database) is correct. Adjust these items, then rerun IMPORT FOREIGN SCHEMA or REFRESH FOREIGN TABLE.
Scenario: IMPORT FOREIGN SCHEMA public LIMIT TO (table1) but remote database has no public schema. Solution: change the statement to IMPORT FOREIGN SCHEMA remote_schema or create public on the remote.
Scenario: FDW user is read-only and lacks USAGE.
Solution: GRANT USAGE ON SCHEMA remote_schema TO fdw_user; followed by REFRESH.
Create a dedicated FDW user with explicit USAGE rights on every needed schema. Automate schema existence checks in CI pipelines and run REFRESH scripts after migrations. Store working IMPORT statements in Galaxy Collections so teammates reuse validated SQL.
Monitor PostgreSQL logs for SQLSTATE HV00P. Alert early to prevent downstream ETL failures.
Document remote schema names in your data catalog.
fdw_schema_not_found (HV00J) appears when a requested schema is absent rather than filtered away. fdw_tablespace_not_found (HV00Q) fires for missing tablespaces. Both fix with CREATE SCHEMA or proper grants.
permission_denied (42501) can masquerade as fdw_no_schemas because lack of USAGE hides schemas. Granting the correct privileges resolves both.
.
Your FDW user can connect but lacks USAGE on any schema, so schema discovery fails while simple connection tests succeed.
No. It means the connection is up but returned zero schemas. Verify permissions and schema names.
Yes. Galaxy’s editor surfaces SQLSTATE codes instantly and lets you share corrected IMPORT statements in a Collection, preventing repeat mistakes.
No. Any FDW that scans remote schemas can raise it, including mysql_fdw and oracle_fdw.
.avif)
.avif){kind=logo}
