PostgreSQL raises HV005 when a foreign-data wrapper tries to bind a local column that no longer exists on the remote object, which typically happens after the remote schema change or a mis-specified fdw_column_name mapping. Aligning the foreign table definition with the remote table (or dropping the dead column) restores the column metadata and lets the query run again.
HV005 is part of the SQL/MED error class that PostgreSQL uses whenever a foreign-data wrapper (FDW) cannot locate a column that the planner believes should exist on the remote side. The FDW layer builds remote queries by walking the columns defined on the local FOREIGN TABLE, which includes both the local column name and the optional remote name supplied via the fdw_column_name option. When the remote server no longer exposes that column—because it was renamed, dropped, or never existed—the FDW raises HV005 before it ever sends the query across the wire. This safeguard keeps PostgreSQL from sending invalid requests to the remote server and allows you to react by reconciling the local foreign table definition with whatever the remote catalog actually contains.
Use psql to describe the foreign table and compare its columns with the ones you expect to query.
-- Show the local column map and id, fdw_column_name options:
\d+ foreign_schema.remote_table
-- Or query the information schema for the FDW mapping:
SELECT column_name, foreign_column_name
FROM information_schema.foreign_table_columns
WHERE foreign_table_schema = 'foreign_schema'
AND foreign_table_name = 'remote_table';If the column mentioned in the HV005 error is listed here, PostgreSQL is trying to send it to the remote server even though the remote copy does not have it.
Connect directly to the remote server (or reuse the same server connection) and list the remote columns. This confirms whether the column exists and how it is spelled/cased.
\c - foreign_server_db
SELECT column_name
FROM information_schema.columns
WHERE table_schema = 'public'
AND table_name = 'actual_table_name';If the column is missing, you now know why FDW raised HV005; if it exists under another name, note the exact spelling.
Drop or rename the stale column on the foreign table, or add a new column that maps to the current remote column name. When you alter a foreign table, you can supply fdw_column_name so PostgreSQL knows the remote identifier.
ALTER FOREIGN TABLE foreign_schema.remote_table
DROP COLUMN missing_column;
ALTER FOREIGN TABLE foreign_schema.remote_table
ADD COLUMN new_column text
OPTIONS (fdw_column_name 'real_remote_name');If multiple columns changed, repeat this step until the local definition mirrors what the remote catalog reports.
When the remote table underwent wholesale changes, it can be easier to drop the foreign table and re-run IMPORT FOREIGN SCHEMA so PostgreSQL rebuilds the column list from scratch.
DROP FOREIGN TABLE IF EXISTS foreign_schema.remote_table;
IMPORT FOREIGN SCHEMA public
LIMIT TO (remote_table)
FROM SERVER remote_server
INTO foreign_schema;This always pulls the current column set. Remember to reapply any custom column-level options, permissions, or triggers afterward.
HV005 corresponds to SQL/MED error fdw_column_name_not_found, which any SQL/MED-compliant FDW can raise when the remote descriptor does not match the local one. PostgreSQL caches the column metadata for foreign tables, so you must issue ALTER FOREIGN TABLE or re-import the schema whenever the remote DDL changes; otherwise the planner refuses to send the invalid column list and surfaces HV005 instead.
Because this check runs before opening the remote connection, you never incur a network round trip for a column that is guaranteed to be missing, which protects the remote server from unnecessary work.
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL
Bind message supplies N parameters but prepared statement requires M
Bind message supplies N parameters but prepared statement requires M in PostgreSQL
Multidimensional arrays must have sub-arrays with matching dimensions
Multidimensional arrays must have sub-arrays with matching dimensions
ERROR: value too long for type character varying
Value too long for type character varying
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL