How to fix HV010: fdw_function_sequence_error in PostgreSQL

Check your foreign table definitions to find out which wrapper is involved:

SELECT
  ft.foreign_table_name,
  fs.srvname AS server_name,
  fdw.fdwname AS wrapper_name
FROM information_schema.foreign_tables ft
JOIN pg_foreign_server fs ON fs.srvname = ft.foreign_server_name
JOIN pg_foreign_data_wrapper fdw ON fdw.oid = fs.srvfdw
WHERE ft.foreign_table_schema = 'public';

Look for custom or third-party FDWs (oracle_fdw, mysql_fdw, mongo_fdw, etc.) in the wrapper_name column. Built-in postgres_fdw rarely triggers HV010 because it's thoroughly tested, so if you see HV010 with postgres_fdw, check for parallel query settings or a very old PostgreSQL version.

Set PostgreSQL logging to verbose mode so you can see which query triggers HV010 and whether parallel workers are involved:

ALTER SYSTEM SET log_error_verbosity = 'verbose';
ALTER SYSTEM SET log_min_messages = 'DEBUG1';
SELECT pg_reload_conf();

Re-run the failing query and examine the PostgreSQL log file. Look for lines mentioning "ForeignScan" or "BeginForeignScan" immediately before the HV010 error. If you see multiple workers logged, parallel execution may be causing the sequence violation.

If parallel workers are triggering the HV010 error, disable parallelism for the session or specific query:

SET max_parallel_workers_per_gather = 0;

Then retry the query. If HV010 disappears, the FDW doesn't properly support parallel scans. Report this to the FDW maintainer and either keep parallelism disabled for queries involving that foreign table or upgrade to a fixed version of the wrapper.

Search the FDW's GitHub repository, mailing list, or issue tracker for "HV010" or "function sequence error". Many third-party FDWs have had bugs related to callback ordering that were fixed in later releases.

Example search for oracle_fdw:

# Clone the repo if needed
git clone https://github.com/laurenz/oracle_fdw.git
cd oracle_fdw
git log --all --grep="HV010\|sequence error" --oneline

If you find a commit that fixes the issue, upgrade your FDW extension to that version or apply the patch manually.

If no update is available, inspect the FDW's C code for improper callback usage. Look for these patterns in the wrapper's source files:

1. Missing state checks: EndForeignScan called without checking if BeginForeignScan was invoked
2. Double cleanup: EndForeignScan or ReScanForeignScan called multiple times on the same scan
3. Unsafe parallel execution: No locking around shared state in parallel query contexts

Example from a hypothetical FDW:

// BAD: No check if scan was started
static void
myEndForeignScan(ForeignScanState *node)
{
    MyFdwState *state = (MyFdwState *) node->fdw_state;
    if (state->cursor != NULL) {  // cursor might not exist yet
        close_cursor(state->cursor);  // Triggers HV010 if BeginForeignScan never ran
    }
}

Add a guard to prevent calling cleanup functions before initialization:

// GOOD: Check state before cleanup
static void
myEndForeignScan(ForeignScanState *node)
{
    MyFdwState *state = (MyFdwState *) node->fdw_state;
    if (state != NULL && state->scan_started && state->cursor != NULL) {
        close_cursor(state->cursor);
        state->scan_started = false;
    }
}

If you're not comfortable modifying C code, file a detailed bug report with the maintainer including your PostgreSQL version, query plan (EXPLAIN output), and the exact HV010 message.