DEV Community: umzzil nng

PostgreSQL HV010 Error: Causes and Solutions Complete Guide

umzzil nng — Sat, 26 Sep 2026 00:03:02 +0000

PostgreSQL Error HV010: fdw_function_sequence_error

HV010 fdw_function_sequence_error occurs when PostgreSQL's Foreign Data Wrapper (FDW) subsystem detects that its internal callback functions have been invoked in an incorrect or unexpected order. This typically surfaces during custom FDW development, extension version mismatches after major upgrades, or abnormal transaction/cursor usage involving foreign tables.

Top 3 Causes

1. FDW Callback Function Order Violation

The FDW API enforces a strict lifecycle: BeginForeignScan → IterateForeignScan → EndForeignScan. Skipping or reordering these callbacks immediately triggers HV010.

-- Check registered FDWs and their handler functions
SELECT fdwname,
       fdwhandler::regproc AS handler,
       fdwvalidator::regproc AS validator
FROM pg_foreign_data_wrapper;

-- Inspect handler function details
SELECT proname, prolang, prosrc
FROM pg_proc
WHERE proname LIKE '%fdw_handler%';

Fix: Drop and recreate the FDW with the correct handler:

-- Remove broken FDW
DROP FOREIGN DATA WRAPPER broken_fdw CASCADE;

-- Recreate with correct handler
CREATE FOREIGN DATA WRAPPER my_fdw
  HANDLER my_fdw_handler
  VALIDATOR my_fdw_validator;

-- Re-register the foreign server
CREATE SERVER my_remote_server
  FOREIGN DATA WRAPPER my_fdw
  OPTIONS (host '10.0.0.1', port '5432', dbname 'targetdb');

2. Extension Version Mismatch After Upgrade

After a PostgreSQL major version upgrade, if ALTER EXTENSION ... UPDATE is not run, the shared library (.so) and SQL catalog may be out of sync, causing internal symbol conflicts that produce HV010.

-- Detect outdated FDW extensions
SELECT name,
       installed_version,
       default_version,
       CASE
           WHEN installed_version <> default_version THEN 'NEEDS UPDATE'
           ELSE 'OK'
       END AS status
FROM pg_available_extensions
WHERE name LIKE '%fdw%'
  AND installed_version IS NOT NULL;

-- Update the extension
ALTER EXTENSION postgres_fdw UPDATE;

-- If corrupted, reinstall completely
DROP EXTENSION postgres_fdw CASCADE;
CREATE EXTENSION postgres_fdw;

3. Abnormal Transaction or Cursor Usage

Using ROLLBACK TO SAVEPOINT mid-scan or closing a cursor before completing a fetch cycle can leave the FDW state machine in an inconsistent state, triggering HV010.

-- Find sessions stuck in FDW-related idle transactions
SELECT pid, usename, state, query, now() - state_change AS idle_duration
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND query ILIKE '%foreign%';

-- Terminate stuck sessions if necessary
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND query ILIKE '%foreign%'
  AND pid <> pg_backend_pid();

-- Use safe transaction pattern with FDW
BEGIN;
SAVEPOINT safe_point;

DO $$
DECLARE r RECORD;
BEGIN
    FOR r IN SELECT * FROM my_foreign_table LOOP
        RAISE NOTICE '%', r;
    END LOOP;
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK TO SAVEPOINT safe_point;
        RAISE;
END;
$$;

COMMIT;

Quick Fix Checklist

Verify FDW extension versions — run ALTER EXTENSION <fdw_name> UPDATE after every major PostgreSQL upgrade.
Drop and recreate broken FDWs — use CASCADE to clean up dependent foreign servers, user mappings, and foreign tables.
Kill idle-in-transaction sessions — use pg_terminate_backend() to release stuck FDW state machines.
Check foreign server connectivity — validate options with SELECT * FROM pg_foreign_server and test with a simple SELECT ... LIMIT 1.

Prevention Tips

Automate version checks: Add a monitoring query to your alerting system that flags any installed FDW extension where installed_version <> default_version.
Wrap all FDW queries in exception handlers: Any PL/pgSQL routine that touches a foreign table should include a proper EXCEPTION WHEN OTHERS block to prevent state corruption from propagating.

-- Reusable FDW health check
CREATE OR REPLACE FUNCTION fdw_server_exists(p_server TEXT)
RETURNS BOOLEAN LANGUAGE plpgsql AS $$
BEGIN
    PERFORM 1 FROM pg_foreign_server WHERE srvname = p_server;
    RETURN FOUND;
EXCEPTION
    WHEN OTHERS THEN RETURN FALSE;
END;
$$;

-- Usage
SELECT fdw_server_exists('my_remote_server');

Related Error Codes

Code	Name	Notes
HV000	fdw_error	Generic FDW error, parent class of HV010
HV005	fdw_column_name_not_found	Column mapping mismatch in foreign table
HV021	fdw_inconsistent_descriptor_information	Schema mismatch between remote and local definition
08001	sqlclient_unable_to_establish_sqlconnection	Connection-level failure, check before HV010

Oracle ORA-16000 Error: Causes and Solutions Complete Guide

umzzil nng — Sat, 26 Sep 2026 00:01:30 +0000

ORA-16000: Database Open for Read-Only Access

ORA-16000 is an Oracle error that occurs when a user attempts a write operation (INSERT, UPDATE, DELETE, DDL) on a database that has been opened in read-only mode. This is most commonly encountered in Oracle Data Guard environments when developers or applications accidentally connect to a Physical Standby database instead of the Primary. Understanding why this happens and how to resolve it quickly is essential for any Oracle DBA or developer.

Top 3 Causes

1. Accidentally Connected to a Data Guard Standby Database

This is the number one cause in production environments. Physical Standby databases in a Data Guard configuration are opened as READ ONLY or READ ONLY WITH APPLY (Active Data Guard). Any write attempt results in ORA-16000.

-- Check if you're connected to a Standby
SELECT NAME, DB_UNIQUE_NAME, DATABASE_ROLE, OPEN_MODE
FROM V$DATABASE;

-- Example output indicating Standby:
-- DATABASE_ROLE    : PHYSICAL STANDBY
-- OPEN_MODE       : READ ONLY WITH APPLY

Fix: Disconnect and reconnect using the Primary database connection string (TNS alias).

2. Database Explicitly Opened in READ ONLY Mode

A DBA may have intentionally opened the database in read-only mode for auditing, data verification, or snapshot analysis using ALTER DATABASE OPEN READ ONLY.

-- Check current open mode
SELECT OPEN_MODE FROM V$DATABASE;

-- To switch back to READ WRITE:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ WRITE;

-- Verify the change
SELECT NAME, OPEN_MODE FROM V$DATABASE;

3. PDB (Pluggable Database) Opened as READ ONLY

In Oracle 12c+ Multitenant environments, an individual PDB can be in READ ONLY mode even when the CDB is fully open for read-write operations.

-- Check all PDB open modes from CDB$ROOT
SELECT CON_ID, NAME, OPEN_MODE
FROM V$PDBS
ORDER BY CON_ID;

-- Reopen specific PDB as READ WRITE
ALTER PLUGGABLE DATABASE your_pdb_name CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE your_pdb_name OPEN READ WRITE;

-- Persist the state across restarts
ALTER PLUGGABLE DATABASE your_pdb_name SAVE STATE;

Quick Fix Solutions

Use this diagnostic script first whenever ORA-16000 is encountered:

-- Universal ORA-16000 diagnostic query
SELECT
    d.NAME              AS db_name,
    d.DATABASE_ROLE     AS role,
    d.OPEN_MODE         AS open_mode,
    d.PROTECTION_MODE   AS protection_mode,
    i.HOST_NAME         AS host
FROM V$DATABASE d, V$INSTANCE i;

Scenario	Fix
Connected to Standby	Reconnect to Primary DB
DB opened READ ONLY	Restart with `OPEN READ WRITE`
PDB is READ ONLY	`ALTER PLUGGABLE DATABASE ... OPEN READ WRITE`

Prevention Tips

1. Standardize TNS Naming for Primary vs. Standby

Use clear, distinct service names such as MYDB_PRW (read-write, Primary only) and MYDB_RO (read-only, Standby). Create a dedicated service on the Primary that fails over automatically with Data Guard Broker so applications always connect to the correct database.

-- Create a Primary-only write service
EXEC DBMS_SERVICE.CREATE_SERVICE('MYDB_WRITE', 'MYDB_WRITE');
EXEC DBMS_SERVICE.START_SERVICE('MYDB_WRITE');

2. Automate Open Mode Monitoring

Schedule a monitoring job to alert DBAs immediately if the database open mode changes unexpectedly from READ WRITE.

-- Use this in a scheduled monitoring script or OEM custom metric
SELECT
    CASE WHEN OPEN_MODE != 'READ WRITE'
         THEN 'ALERT: DB is ' || OPEN_MODE
         ELSE 'OK'
    END AS status,
    NAME, OPEN_MODE, DATABASE_ROLE
FROM V$DATABASE;

Related Oracle Errors

ORA-16004 — Backup database requires recovery; common in Data Guard setups alongside ORA-16000.
ORA-01219 — Database not open; can appear during incorrect open mode transitions.
ORA-01552 — Cannot use system rollback segment on read-only database.

PostgreSQL HV002 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 14:03:01 +0000

PostgreSQL Error HV002: fdw dynamic parameter value needed

PostgreSQL error HV002 occurs within the Foreign Data Wrapper (FDW) subsystem when a dynamic parameter value is required at runtime but has not been supplied. This typically surfaces when executing parameterized queries or prepared statements that involve foreign tables, where the FDW layer cannot resolve a bound parameter before pushing the query to the remote server. It is commonly seen with postgres_fdw, mysql_fdw, and other FDW implementations.

Top 3 Causes

1. Missing Parameter Binding in Prepared Statements

When executing a prepared statement against a foreign table, failing to supply all required parameter values triggers HV002. The FDW layer validates parameter completeness before forwarding the query remotely.

-- Problematic: parameter $1 not supplied at EXECUTE time
PREPARE fetch_remote (int) AS
  SELECT * FROM foreign_orders WHERE customer_id = $1;

EXECUTE fetch_remote;  -- HV002 raised here

-- Fix: always supply all parameters
EXECUTE fetch_remote(12345);

2. Incomplete FDW Server or User Mapping Configuration

Missing required options in CREATE SERVER or CREATE USER MAPPING can cause the FDW connector to fail when attempting to resolve dynamic connection parameters at query execution time.

-- Check current server options
SELECT srvname, srvoptions FROM pg_foreign_server;

-- Fix: ensure all required options are present
ALTER SERVER remote_pg_server
OPTIONS (
  SET host 'remote-db.example.com',
  SET port '5432',
  SET dbname 'production_db'
);

-- Fix: ensure user mapping is complete
DROP USER MAPPING IF EXISTS FOR current_user SERVER remote_pg_server;

CREATE USER MAPPING FOR current_user
SERVER remote_pg_server
OPTIONS (
  user 'app_user',
  password 'strongpassword'
);

3. FDW Extension Version Mismatch or Bug

Certain versions of FDW extensions contain bugs in dynamic parameter handling. A mismatch between the PostgreSQL server version and the FDW extension version can cause HV002 even for syntactically valid queries.

-- Check installed FDW extension versions
SELECT extname, extversion
FROM pg_extension
WHERE extname LIKE '%fdw%';

-- Update the extension
ALTER EXTENSION postgres_fdw UPDATE;

-- Workaround: disable remote parameter pushdown temporarily
ALTER FOREIGN TABLE foreign_orders
OPTIONS (SET use_remote_estimate 'false');

-- Debug with verbose explain
EXPLAIN (VERBOSE, ANALYZE)
SELECT * FROM foreign_orders WHERE customer_id = 42;

Quick Fix Solutions

Always use EXECUTE ... USING for dynamic SQL targeting foreign tables to ensure explicit parameter binding.
Verify FDW server and user mapping options via pg_foreign_server and pg_user_mappings after any configuration change.
Keep FDW extensions up to date using ALTER EXTENSION <name> UPDATE.

-- Safe dynamic query pattern using USING clause
DO $$
DECLARE
  v_id INT := 42;
  v_sql TEXT := 'SELECT order_id FROM foreign_orders WHERE customer_id = $1';
BEGIN
  EXECUTE v_sql USING v_id;
END;
$$;

Prevention Tips

Validate parameters before execution: Add NULL checks and type validation before executing any parameterized query against FDW tables.
Automate FDW health checks: Schedule a periodic query against pg_foreign_server, pg_foreign_table, and pg_user_mappings to detect configuration drift before it causes runtime errors in production.

Related Errors

HV000 – General FDW error, the parent error class for HV002.
HV00P – Invalid FDW option name; often co-occurs with HV002 during misconfiguration.
HV005 – FDW column name not found; related to schema mismatch on remote tables.

Oracle ORA-14501 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 14:01:22 +0000

ORA-14501: Object Is Not Partitioned — Causes, Fixes & Prevention

ORA-14501 is thrown by Oracle when you attempt to execute a partition-specific DDL or DML command against a table or index that is not actually partitioned. In simple terms, Oracle refuses the command because the target object has no partition structure to operate on. This error commonly surfaces during maintenance scripts, environment migrations, or automated batch jobs where partition validation is overlooked.

Top 3 Causes

1. Running Partition DDL Against a Regular Table

The most frequent cause. A script written for a partitioned table gets executed on a standard heap table — perhaps because the table structure differs between environments.

-- This will throw ORA-14501 if ORDERS is NOT a partitioned table
ALTER TABLE orders DROP PARTITION orders_2022;

-- Always verify first
SELECT table_name, partitioned
FROM   user_tables
WHERE  table_name = 'ORDERS';
-- If PARTITIONED = 'NO', the table is NOT partitioned

2. Applying Partition Commands to a Global Non-Partitioned Index

A table can be partitioned while its index is not. Mistaking a Global Non-Partitioned Index for a partitioned index leads to this error.

-- Check index partitioning status
SELECT index_name, partitioned
FROM   user_indexes
WHERE  table_name = 'ORDERS';

-- This fails if the index is NOT partitioned
ALTER INDEX idx_orders_date REBUILD PARTITION orders_idx_2022;

-- Correct rebuild for a non-partitioned index
ALTER INDEX idx_orders_date REBUILD;

3. Automated Scripts Without Partition Validation

Batch maintenance jobs that loop over multiple objects and apply partition operations without checking each object's partition status will eventually hit a non-partitioned table.

-- Safe PL/SQL pattern with validation
DECLARE
  v_partitioned VARCHAR2(3);
BEGIN
  SELECT partitioned
  INTO   v_partitioned
  FROM   user_tables
  WHERE  table_name = 'ORDERS';

  IF v_partitioned = 'YES' THEN
    EXECUTE IMMEDIATE
      'ALTER TABLE orders DROP PARTITION orders_2022';
    DBMS_OUTPUT.PUT_LINE('Partition dropped successfully.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Skipped: table is not partitioned.');
  END IF;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    DBMS_OUTPUT.PUT_LINE('Table not found.');
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM);
END;
/

Quick Fix Solutions

Step 1 — Confirm partitioning status before any action:

-- For tables
SELECT table_name, partitioned
FROM   user_tables
WHERE  table_name = 'YOUR_TABLE';

-- For indexes
SELECT index_name, partitioned
FROM   user_indexes
WHERE  index_name = 'YOUR_INDEX';

Step 2 — If the object IS partitioned, list available partitions:

-- List table partitions
SELECT partition_name, high_value, num_rows
FROM   user_tab_partitions
WHERE  table_name = 'YOUR_TABLE'
ORDER  BY partition_position;

Step 3 — If the object is NOT partitioned, use standard SQL instead:

-- Replace DROP PARTITION with DELETE for non-partitioned tables
DELETE FROM your_table
WHERE  created_date < ADD_MONTHS(SYSDATE, -12);
COMMIT;

Prevention Tips

Always validate before executing partition DDL. Make it a coding standard to query user_tables.partitioned or user_indexes.partitioned at the top of every partition-related script. Integrate this check into your CI/CD pipeline to catch mismatches before they reach production.
Keep object structures in sync across environments. Regularly compare DDL between development, staging, and production using DBMS_METADATA.GET_DDL. Structural drift — where a table is partitioned in dev but not in prod — is the root cause of most ORA-14501 incidents in real-world operations.

Related Errors

ORA-14006 — Invalid partition name specified
ORA-02149 — Specified partition does not exist
ORA-14300 — Partition key value exceeds the range of the last partition
ORA-14502 — Object is not a composite-partitioned table

PostgreSQL HV005 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 10:02:55 +0000

PostgreSQL Error HV005: fdw_column_name_not_found

The HV005: fdw_column_name_not_found error occurs when PostgreSQL's Foreign Data Wrapper (FDW) cannot locate a specified column name in the remote data source. This typically happens when the local Foreign Table definition is out of sync with the actual remote table schema. It can appear across various FDW implementations including postgres_fdw, mysql_fdw, and oracle_fdw.

Top 3 Causes

1. Column Name Mismatch Between Foreign Table and Remote Table

The most common cause is a typo or naming convention difference between the local Foreign Table column and the actual remote column name.

-- WRONG: Remote table has 'user_name', but local foreign table defines 'username'
CREATE FOREIGN TABLE ft_users (
    id       integer,
    username varchar(100)   -- ❌ remote column is actually 'user_name'
)
SERVER remote_pg_server
OPTIONS (schema_name 'public', table_name 'users');

-- CORRECT: Use OPTIONS to map local name to remote column name
CREATE FOREIGN TABLE ft_users (
    id       integer        OPTIONS (column_name 'id'),
    username varchar(100)   OPTIONS (column_name 'user_name')  -- ✅ explicit mapping
)
SERVER remote_pg_server
OPTIONS (schema_name 'public', table_name 'users');

2. Remote Schema Changed Without Updating Foreign Table

If someone runs ALTER TABLE or renames a column on the remote server, the local Foreign Table definition becomes stale and triggers HV005.

-- Re-sync by re-importing the foreign schema
DROP FOREIGN TABLE IF EXISTS ft_users;

IMPORT FOREIGN SCHEMA public
    LIMIT TO (users)
    FROM SERVER remote_pg_server
    INTO local_schema;

-- Verify the re-imported columns
SELECT column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'local_schema'
  AND table_name   = 'users'
ORDER BY ordinal_position;

3. Incorrect `OPTIONS (column_name ...)` Value

Specifying a wrong remote column name in the column_name option of a Foreign Table column will directly cause this error.

-- Fix an incorrect column_name option on an existing foreign table
ALTER FOREIGN TABLE ft_users
    ALTER COLUMN username OPTIONS (SET column_name 'user_name');

-- Check current column option mappings
SELECT
    a.attname        AS local_column,
    fao.option_value AS remote_column
FROM pg_attribute a
JOIN pg_class c ON c.oid = a.attrelid
LEFT JOIN pg_options_to_table(a.attfdwoptions)
    AS fao(option_name text, option_value text) ON fao.option_name = 'column_name'
WHERE c.relname = 'ft_users'
  AND a.attnum > 0
  AND NOT a.attisdropped;

Quick Fix Solutions

-- Step 1: Verify remote table columns via dblink
SELECT col_name
FROM dblink(
    'host=remote_host dbname=mydb user=myuser password=mypass',
    'SELECT column_name FROM information_schema.columns WHERE table_name = ''users'''
) AS t(col_name text);

-- Step 2: Drop and recreate the foreign table with correct names
DROP FOREIGN TABLE IF EXISTS ft_users;

CREATE FOREIGN TABLE ft_users (
    id         integer      OPTIONS (column_name 'id'),
    user_name  varchar(100) OPTIONS (column_name 'user_name'),
    email      varchar(255) OPTIONS (column_name 'email')
)
SERVER remote_pg_server
OPTIONS (schema_name 'public', table_name 'users');

-- Step 3: Test the foreign table access
SELECT * FROM ft_users LIMIT 5;

Prevention Tips

1. Use IMPORT FOREIGN SCHEMA for reliable sync.
Instead of manually writing Foreign Table DDL, always use IMPORT FOREIGN SCHEMA to auto-generate accurate definitions directly from the remote source. Schedule periodic re-imports when remote schemas are subject to change.

-- Automate re-sync in a maintenance script
DO $$
BEGIN
    EXECUTE 'DROP FOREIGN TABLE IF EXISTS local_schema.users';
    EXECUTE 'IMPORT FOREIGN SCHEMA public LIMIT TO (users)
             FROM SERVER remote_pg_server INTO local_schema';
    RAISE NOTICE 'Sync done: %', now();
END;
$$;

2. Add schema validation to your CI/CD pipeline.
Before deploying, run a diff query comparing local Foreign Table columns against remote columns. If the result returns any rows, fail the deployment and alert the team.

-- Detect column mismatches before deployment
WITH local_cols  AS (SELECT attname AS col FROM pg_attribute
                     WHERE attrelid = 'local_schema.ft_users'::regclass
                       AND attnum > 0 AND NOT attisdropped),
     remote_cols AS (SELECT col_name AS col FROM dblink('...conn...','
                     SELECT column_name FROM information_schema.columns
                     WHERE table_name=''users''') AS t(col_name text))
SELECT 'MISMATCH' AS status, col FROM local_cols
WHERE col NOT IN (SELECT col FROM remote_cols);
-- Zero rows = safe to deploy ✅

Related Errors

Code	Name	Notes
HV000	fdw_error	Generic parent error for all FDW issues
HV00P	fdw_option_name_not_found	Invalid option name in OPTIONS clause
HV021	fdw_inconsistent_descriptor_information	Column type mismatch in FDW descriptor
HV002	fdw_dynamic_parameter_value_needed	Missing required dynamic FDW parameter

Oracle ORA-14427 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 10:01:22 +0000

ORA-14427: table does not have ROW MOVEMENT enabled

ORA-14427 is an Oracle error that occurs when you attempt an operation requiring row relocation on a table that has not had ROW MOVEMENT enabled. This most commonly happens with partitioned tables when updating a partition key column, or when using the Flashback Table feature. Since Oracle disables ROW MOVEMENT by default, you must explicitly enable it before performing such operations.

Top 3 Causes

1. Updating a Partition Key Column on a Partitioned Table

When you update the partition key column of a row in a partitioned table, Oracle needs to physically move that row to a different partition. Without ROW MOVEMENT enabled, Oracle refuses this operation and raises ORA-14427.

-- This will raise ORA-14427 if ROW MOVEMENT is disabled
UPDATE sales
SET sale_date = DATE '2024-03-01'
WHERE sale_id = 5001;

-- Fix: Enable ROW MOVEMENT first
ALTER TABLE sales ENABLE ROW MOVEMENT;

-- Now the UPDATE will succeed
UPDATE sales
SET sale_date = DATE '2024-03-01'
WHERE sale_id = 5001;

COMMIT;

2. Using Flashback Table Without ROW MOVEMENT Enabled

Oracle's Flashback Table feature restores a table to a previous point in time. Because this process can change existing ROWIDs, Oracle requires ROW MOVEMENT to be enabled before executing a FLASHBACK TABLE statement.

-- Step 1: Enable ROW MOVEMENT
ALTER TABLE employees ENABLE ROW MOVEMENT;

-- Step 2: Flashback the table to a specific timestamp
FLASHBACK TABLE employees TO TIMESTAMP
    TO_TIMESTAMP('2024-05-01 09:00:00', 'YYYY-MM-DD HH24:MI:SS');

-- Step 3: Optionally disable after the operation
ALTER TABLE employees DISABLE ROW MOVEMENT;

3. Partition Maintenance and Data Migration Scripts

Bulk data migration or partition reorganization scripts often update partition key values en masse. If ROW MOVEMENT is not enabled beforehand, even a single row requiring a partition change will cause the entire batch to fail with ORA-14427.

-- Check ROW MOVEMENT status before running migration
SELECT table_name, partitioned, row_movement
FROM dba_tables
WHERE owner = 'APPUSER'
  AND partitioned = 'YES'
  AND row_movement = 'DISABLED';

-- Bulk enable ROW MOVEMENT for all partitioned tables in a schema
BEGIN
    FOR rec IN (
        SELECT table_name
        FROM dba_tables
        WHERE owner = 'APPUSER'
          AND partitioned = 'YES'
          AND row_movement = 'DISABLED'
    ) LOOP
        EXECUTE IMMEDIATE
            'ALTER TABLE APPUSER.' || rec.table_name || ' ENABLE ROW MOVEMENT';
    END LOOP;
END;
/

Quick Fix

The immediate fix is straightforward — enable ROW MOVEMENT on the affected table:

-- Enable ROW MOVEMENT
ALTER TABLE <table_name> ENABLE ROW MOVEMENT;

-- Verify the change
SELECT table_name, row_movement
FROM dba_tables
WHERE table_name = '<TABLE_NAME>';

If you need to disable it again after completing your operation:

ALTER TABLE <table_name> DISABLE ROW MOVEMENT;

Prevention Tips

Enable ROW MOVEMENT at table creation time for all partitioned tables where partition key updates are possible. Make this a standard part of your DDL templates.

CREATE TABLE orders (
    order_id    NUMBER,
    order_date  DATE,
    customer_id NUMBER,
    total       NUMBER(15,2)
)
ENABLE ROW MOVEMENT
PARTITION BY RANGE (order_date) (
    PARTITION p_2023 VALUES LESS THAN (DATE '2024-01-01'),
    PARTITION p_2024 VALUES LESS THAN (DATE '2025-01-01'),
    PARTITION p_future VALUES LESS THAN (MAXVALUE)
);

Schedule a regular audit query to identify partitioned tables with ROW MOVEMENT disabled. Incorporate this into your weekly DBA health-check reports to catch issues before they surface in production.

-- Weekly audit: partitioned tables missing ROW MOVEMENT
SELECT owner, table_name, num_rows, row_movement
FROM dba_tables
WHERE partitioned = 'YES'
  AND row_movement = 'DISABLED'
  AND owner NOT IN ('SYS', 'SYSTEM', 'DBSNMP')
ORDER BY owner, table_name;

Related Errors

ORA-14402 — Raised when updating a partition key column would cause a partition change and ROW MOVEMENT is disabled.
ORA-08189 — Specifically raised during Flashback Table when ROW MOVEMENT is not enabled.
ORA-14400 — Occurs when an inserted or updated partition key value does not map to any existing partition.

PostgreSQL HV000 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 06:02:52 +0000

PostgreSQL Error HV000: FDW Error — Causes, Fixes, and Prevention

PostgreSQL error code HV000 is a general-purpose error belonging to the Foreign Data Wrapper (FDW) error class. It occurs when PostgreSQL encounters an unexpected problem while connecting to or processing data from an external data source such as another PostgreSQL instance, MySQL, or a flat file. Because HV000 is a catch-all code for the FDW error family, the actual root cause must be identified from the accompanying error message.

Top 3 Causes

1. External Server Connection Failure

The most common cause is an inability to reach the remote server due to incorrect server options, firewall rules, or the remote host being unavailable.

-- Check registered foreign servers
SELECT srvname, srvoptions
FROM pg_foreign_server;

-- Fix incorrect server options
ALTER SERVER my_remote_server
OPTIONS (
    SET host 'correct-host.example.com',
    SET port '5432',
    SET dbname 'target_db'
);

-- Quick connection test
SELECT * FROM my_foreign_table LIMIT 1;

2. Invalid User Mapping or Credentials

When the password for a remote account changes but the local USER MAPPING is not updated, authentication fails and triggers HV000.

-- Check current user mappings
SELECT umuser::regrole, umoptions, srvname
FROM pg_user_mappings;

-- Update credentials in the user mapping
ALTER USER MAPPING FOR current_user
SERVER my_remote_server
OPTIONS (
    SET user 'remote_user',
    SET password 'updated_password'
);

3. Foreign Table Schema Mismatch

If the remote table's schema changes (e.g., a column is added, renamed, or its type is altered) but the local foreign table definition is not updated, queries will fail with HV000.

-- Drop the outdated foreign table and recreate it
DROP FOREIGN TABLE IF EXISTS my_foreign_table;

CREATE FOREIGN TABLE my_foreign_table (
    id          BIGINT,
    username    VARCHAR(100),
    email       TEXT,
    created_at  TIMESTAMP WITH TIME ZONE
)
SERVER my_remote_server
OPTIONS (schema_name 'public', table_name 'users');

-- Or use IMPORT FOREIGN SCHEMA to auto-sync
IMPORT FOREIGN SCHEMA public
    LIMIT TO (users, orders)
    FROM SERVER my_remote_server
    INTO local_schema;

Quick Fix Checklist

Verify the remote host is reachable and the port is open.
Confirm USER MAPPING credentials are current.
Re-sync foreign table definitions using IMPORT FOREIGN SCHEMA.
Check PostgreSQL logs on both the local and remote servers for detailed error messages.

-- Retrieve FDW-related errors from pg_stat_activity
SELECT pid, state, query, wait_event_type, wait_event
FROM pg_stat_activity
WHERE query ILIKE '%foreign%'
  AND state != 'idle';

Prevention Tips

1. Automate connection health checks.
Schedule a lightweight query against each foreign table using a cron job or monitoring tool. Catch failures before they impact production.

-- Simple health check function
CREATE OR REPLACE FUNCTION fdw_health_check(p_table TEXT)
RETURNS BOOLEAN AS $$
BEGIN
    EXECUTE format('SELECT 1 FROM %I LIMIT 1', p_table);
    RETURN TRUE;
EXCEPTION WHEN OTHERS THEN
    RAISE WARNING 'FDW check failed for %: %', p_table, SQLERRM;
    RETURN FALSE;
END;
$$ LANGUAGE plpgsql;

2. Include schema re-import in your deployment pipeline.
Whenever the remote schema changes, run IMPORT FOREIGN SCHEMA as part of your CI/CD process to keep local foreign table definitions in sync and avoid mismatch errors in production.

Oracle ORA-14424 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 06:01:20 +0000

ORA-14424: Cannot Shrink a Segment That Does Not Have Row Movement Enabled

ORA-14424 occurs in Oracle Database when you attempt to shrink a table or segment using ALTER TABLE ... SHRINK SPACE without first enabling the ROW MOVEMENT feature on that object. Oracle's shrink operation physically relocates rows within the segment to reclaim fragmented free space, which requires row movement to be explicitly enabled. This error is commonly encountered during space reclamation tasks after large-scale data deletions.

Top 3 Causes

1. ROW MOVEMENT Not Enabled on the Target Table

By default, Oracle creates tables with ROW MOVEMENT disabled. Any attempt to run SHRINK SPACE without enabling it will immediately raise ORA-14424.

-- Check current ROW MOVEMENT status
SELECT table_name, row_movement
FROM dba_tables
WHERE table_name = 'YOUR_TABLE'
  AND owner = 'YOUR_SCHEMA';

-- This will fail if ROW MOVEMENT is DISABLED
ALTER TABLE your_schema.your_table SHRINK SPACE;
-- ORA-14424: cannot shrink a segment that does not have row movement enabled

2. Partitioned Table SHRINK Without Table-Level ROW MOVEMENT

When attempting to shrink a specific partition of a partitioned table, ROW MOVEMENT must be enabled at the table level, not the partition level. Overlooking this distinction is a common mistake.

-- Incorrect assumption: trying to shrink a partition directly
ALTER TABLE your_schema.sales_part
  MODIFY PARTITION sales_2023 SHRINK SPACE;
-- Fails if ROW MOVEMENT is not enabled on the table

-- Correct approach: enable at table level first
ALTER TABLE your_schema.sales_part ENABLE ROW MOVEMENT;

ALTER TABLE your_schema.sales_part
  MODIFY PARTITION sales_2023 SHRINK SPACE;

3. LOB Segment SHRINK Without Enabling ROW MOVEMENT

Tables containing LOB columns require ROW MOVEMENT to be enabled on the parent table before shrinking the LOB segment. Skipping this step results in ORA-14424.

-- Check LOB segments in a table
SELECT column_name, segment_name, tablespace_name
FROM dba_lobs
WHERE table_name = 'YOUR_TABLE'
  AND owner = 'YOUR_SCHEMA';

-- Enable ROW MOVEMENT before LOB shrink
ALTER TABLE your_schema.your_table ENABLE ROW MOVEMENT;

-- Shrink the LOB segment
ALTER TABLE your_schema.your_table
  MODIFY LOB (your_lob_column) (SHRINK SPACE);

Quick Fix Solutions

The fix is straightforward: enable ROW MOVEMENT before running SHRINK, then optionally disable it afterward.

-- Step 1: Enable ROW MOVEMENT
ALTER TABLE your_schema.your_table ENABLE ROW MOVEMENT;

-- Step 2: Shrink the segment (reclaim fragmented space)
ALTER TABLE your_schema.your_table SHRINK SPACE;

-- Step 3: Shrink including indexes (CASCADE)
ALTER TABLE your_schema.your_table SHRINK SPACE CASCADE;

-- Step 4: (Optional) Disable ROW MOVEMENT after completion
ALTER TABLE your_schema.your_table DISABLE ROW MOVEMENT;

For bulk operations across multiple tables:

BEGIN
  FOR rec IN (
    SELECT owner, table_name
    FROM dba_tables
    WHERE owner = 'YOUR_SCHEMA'
      AND row_movement = 'DISABLED'
  ) LOOP
    BEGIN
      EXECUTE IMMEDIATE 'ALTER TABLE ' || rec.owner || '.' || rec.table_name
                        || ' ENABLE ROW MOVEMENT';
      EXECUTE IMMEDIATE 'ALTER TABLE ' || rec.owner || '.' || rec.table_name
                        || ' SHRINK SPACE CASCADE';
      DBMS_OUTPUT.PUT_LINE('Processed: ' || rec.table_name);
    EXCEPTION
      WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE('Failed: ' || rec.table_name || ' - ' || SQLERRM);
    END;
  END LOOP;
END;
/

Prevention Tips

Enable ROW MOVEMENT at table creation for tables that undergo frequent large deletes, so space reclamation scripts never fail unexpectedly.

CREATE TABLE your_schema.your_table (
  id   NUMBER PRIMARY KEY,
  name VARCHAR2(100)
)
ENABLE ROW MOVEMENT;

Add a pre-check in your maintenance scripts to automatically verify and enable ROW MOVEMENT before any SHRINK operation, and log before/after segment sizes to validate space savings.

Related Errors

ORA-10636 – Internal row movement failure during shrink operations.
ORA-14412 – Shrink not supported for certain partition or subpartition types.
ORA-01654 – Tablespace out of space; verify free space before running SHRINK.

PostgreSQL F0001 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 00:03:17 +0000

PostgreSQL F0001: lock file exists — What It Means and How to Fix It

The PostgreSQL error code F0001: lock file exists occurs when the server attempts to start but finds an existing postmaster.pid file in the data directory. This file acts as a guard to prevent two PostgreSQL instances from accessing the same data directory simultaneously. When the server shuts down abnormally — due to a crash, power loss, or forced kill — this file is not cleaned up, causing the next startup attempt to fail.

Top 3 Causes

1. Leftover PID File After Abnormal Shutdown

The most common cause is a server killed via SIGKILL, an OOM killer event, or sudden power loss that leaves postmaster.pid behind. Normal shutdowns (pg_ctl stop or systemctl stop postgresql) always clean up this file, but forced terminations skip this step entirely.

-- After restarting, verify the server is healthy
SELECT version();

-- Check for any incomplete transactions left behind
SELECT pid, usename, state, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

-- Force a checkpoint to confirm WAL integrity
CHECKPOINT;

2. Duplicate Instance Launch Attempts

Running two startup commands against the same $PGDATA — such as a systemd service and a manual pg_ctl start firing simultaneously — triggers this error. This is especially common in Docker environments where a container restarts but the volume still holds the old postmaster.pid.

-- Once running, confirm only one postmaster is active
-- Run this from the terminal first:
-- ps aux | grep postgres | grep -v grep

-- Then verify from inside PostgreSQL
SELECT pg_postmaster_start_time(), pg_conf_load_time();

-- Check current data directory
SHOW data_directory;

3. NFS or Shared Storage Mount Issues

When $PGDATA resides on NFS or SAN storage, a network interruption or remount can leave the PID file stranded on the shared volume. File locking semantics on NFS are notoriously unreliable, and the PID file may persist even after PostgreSQL has truly stopped.

-- After recovery from shared storage issues, check for corruption
VACUUM VERBOSE ANALYZE;

-- Verify table-level integrity
SELECT schemaname, tablename,
       n_live_tup, n_dead_tup,
       last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Quick Fix Solutions

-- Step 1: Check if a real PostgreSQL process is running
-- (Run in terminal, not psql)
-- ps aux | grep postgres
-- cat $PGDATA/postmaster.pid   # First line is the PID

-- Step 2: If NO process is running, remove the stale lock file
-- rm -f $PGDATA/postmaster.pid

-- Step 3: Start PostgreSQL
-- pg_ctl start -D $PGDATA
-- or
-- systemctl start postgresql

-- Step 4: After startup, confirm clean recovery
SELECT pg_is_in_recovery();   -- Should return false for primary

-- Step 5: Check background writer for signs of crash
SELECT checkpoints_req, buffers_backend_fsync, stats_reset
FROM pg_stat_bgwriter;

For Docker/container environments:

-- Remove stale PID file inside the container
-- docker exec -it <container> rm -f /var/lib/postgresql/data/postmaster.pid
-- docker restart <container>

-- Verify successful startup
-- docker logs <container> | tail -20

Prevention Tips

1. Always use graceful shutdown commands.
Never use kill -9 on PostgreSQL processes. Always prefer pg_ctl stop -m fast or systemctl stop postgresql, and give the server adequate time to shut down cleanly by configuring TimeoutStopSec in systemd.

-- Before shutting down, check for long-running transactions
SELECT pid, usename, now() - query_start AS duration, state, query
FROM pg_stat_activity
WHERE state <> 'idle'
  AND now() - query_start > INTERVAL '1 minute'
ORDER BY duration DESC;

-- Terminate idle connections cleanly before planned maintenance
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
  AND now() - state_change > INTERVAL '10 minutes';

2. Add a health-check script to your monitoring pipeline.
Set up a cron job or monitoring alert (Prometheus, Nagios, Zabbix) that cross-references the existence of postmaster.pid with actual running processes. If the file exists but no process is found, trigger an alert immediately rather than discovering the problem at the next startup.

-- postgresql.conf recommended settings to reduce crash risk
-- shared_buffers = 25% of total RAM
-- checkpoint_completion_target = 0.9
-- max_wal_size = 2GB
-- wal_level = replica  (enables point-in-time recovery)

-- Confirm current settings from inside psql
SHOW shared_buffers;
SHOW checkpoint_completion_target;
SHOW max_wal_size;

Summary

Step	Action
Diagnose	Check if a real PostgreSQL process is running
Fix	Remove stale `postmaster.pid` only after confirming no active process
Verify	Run `CHECKPOINT` and inspect `pg_stat_bgwriter` after restart
Prevent	Use graceful shutdown; monitor PID file vs. process state

The F0001 error looks scary but is almost always straightforward to resolve — the key is patience and verification before deleting any files.

Oracle ORA-14411 Error: Causes and Solutions Complete Guide

umzzil nng — Fri, 25 Sep 2026 00:01:40 +0000

ORA-14411: The DDL Cannot Be Run Concurrently with Other DDLs

ORA-14411 is thrown by Oracle when two or more DDL operations attempt to run simultaneously against the same object, particularly partitioned tables or shared dictionary objects. Oracle enforces serialization on certain DDL operations to protect the integrity of the data dictionary, and when a conflict is detected, it raises this error rather than allowing a potentially corrupted state. This error is especially common in automated ETL pipelines and batch maintenance scripts that manage partitions in parallel.

Top 3 Causes

1. Concurrent Partition DDL Operations

Running ADD PARTITION, DROP PARTITION, or EXCHANGE PARTITION from multiple sessions at the same time on the same table is the most frequent trigger for ORA-14411.

-- Session 1 (runs first)
ALTER TABLE sales ADD PARTITION p_2025_q1
    VALUES LESS THAN (TO_DATE('2025-04-01', 'YYYY-MM-DD'));

-- Session 2 (runs at the same time — causes ORA-14411)
ALTER TABLE sales ADD PARTITION p_2025_q2
    VALUES LESS THAN (TO_DATE('2025-07-01', 'YYYY-MM-DD'));

-- Check which session holds the DDL lock
SELECT s.sid, s.serial#, s.username, dl.name, dl.mode_held
FROM   v$session s, dba_ddl_locks dl
WHERE  s.sid = dl.session_id;

2. DDL During Online Table Redefinition

When DBMS_REDEFINITION is in progress, any external DDL against the same table will fail with ORA-14411 because the redefinition process internally holds dictionary locks throughout its execution.

-- Check if redefinition is currently active
SELECT * FROM dba_redefinition_status;

-- Wrong: Running DDL while redefinition is active
ALTER TABLE sales ADD (new_column VARCHAR2(50));  -- ORA-14411

-- Correct: Finish redefinition first, then apply DDL
BEGIN
    DBMS_REDEFINITION.FINISH_REDEF_TABLE(
        uname      => 'SCOTT',
        orig_table => 'SALES',
        int_table  => 'SALES_INTERIM'
    );
END;
/
-- Now it is safe to run DDL
ALTER TABLE sales ADD (new_column VARCHAR2(50));

3. Parallel Index Rebuild on the Same Table

Rebuilding multiple partitioned indexes simultaneously on the same table using multiple sessions or parallel scripts can also trigger ORA-14411.

-- Problematic: Two sessions rebuilding indexes on same table simultaneously
-- Session 1
ALTER INDEX sales_local_idx REBUILD PARTITION p_2024_q3 PARALLEL 8;
-- Session 2 (at the same time — may raise ORA-14411)
ALTER INDEX sales_global_idx REBUILD PARALLEL 8;

-- Safe approach: Serialize using a PL/SQL loop
BEGIN
    FOR r IN (
        SELECT index_name, partition_name
        FROM   dba_ind_partitions
        WHERE  table_owner = 'SCOTT'
        AND    status      = 'UNUSABLE'
        ORDER BY index_name
    ) LOOP
        EXECUTE IMMEDIATE
            'ALTER INDEX ' || r.index_name ||
            ' REBUILD PARTITION ' || r.partition_name;
        DBMS_OUTPUT.PUT_LINE('Done: ' || r.index_name || ' / ' || r.partition_name);
    END LOOP;
END;
/

Quick Fix Solutions

Identify and wait for the conflicting session — Use DBA_DDL_LOCKS to find which session holds the lock and wait for it to complete before retrying your DDL.
Serialize DDL execution — Wrap all partition management DDL inside a single PL/SQL block or use DBMS_SCHEDULER with a single-threaded job to avoid concurrent execution.
Implement retry logic — Catch ORA-14411 (SQLCODE = -14411) in your exception handler and retry after a short sleep using DBMS_LOCK.SLEEP.

-- Retry wrapper example
DECLARE
    v_retries NUMBER := 0;
BEGIN
    LOOP
        BEGIN
            EXECUTE IMMEDIATE
                'ALTER TABLE sales DROP PARTITION p_old';
            EXIT;  -- Success, exit loop
        EXCEPTION
            WHEN OTHERS THEN
                IF SQLCODE = -14411 AND v_retries < 3 THEN
                    v_retries := v_retries + 1;
                    DBMS_LOCK.SLEEP(10);  -- Wait 10 seconds and retry
                ELSE
                    RAISE;
                END IF;
        END;
    END LOOP;
END;
/

Prevention Tips

Use DBMS_SCHEDULER for serialized DDL jobs — Schedule all partition maintenance tasks as single-threaded scheduler jobs with defined time windows so they never overlap.
Pre-check DDL locks before execution — Always query DBA_DDL_LOCKS at the start of any maintenance script to confirm no conflicting locks exist before issuing DDL statements.

Related Errors

ORA-00054: Resource busy with NOWAIT — often seen alongside ORA-14411 in lock contention scenarios.
ORA-04021: Lock timeout exceeded — occurs when DDL waits too long for a lock to be released.
ORA-14400: Partition key mapping error — commonly seen in partition DDL workflows.

PostgreSQL F0000 Error: Causes and Solutions Complete Guide

umzzil nng — Thu, 24 Sep 2026 14:03:08 +0000

PostgreSQL F0000: Config File Error — Causes, Fixes & Prevention

PostgreSQL error code F0000 signals a configuration file error, occurring when the server fails to parse or load one of its core configuration files such as postgresql.conf, pg_hba.conf, or pg_ident.conf. This error can surface during server startup or when dynamically reloading configuration via pg_reload_conf(). Because it directly affects server availability and client connectivity, resolving it quickly is critical for any production environment.

Top 3 Causes

1. Syntax Errors or Invalid Values in `postgresql.conf`

Typos, unsupported parameter names, or out-of-range values in postgresql.conf are the most common triggers. A single malformed line can prevent the entire configuration from loading correctly.

-- Check current parameter settings and their source files
SELECT name, setting, source, sourcefile, sourceline
FROM pg_settings
WHERE name IN ('shared_buffers', 'work_mem', 'max_connections');

-- Safely change settings using ALTER SYSTEM (validates syntax immediately)
ALTER SYSTEM SET shared_buffers = '256MB';
ALTER SYSTEM SET work_mem = '16MB';

-- Reload and verify
SELECT pg_reload_conf();

-- Check for parameters requiring a full restart
SELECT name, setting, pending_restart
FROM pg_settings
WHERE pending_restart = true;

2. Malformed Rules in `pg_hba.conf`

Invalid CIDR notation, unsupported authentication methods, or incorrect record field ordering in pg_hba.conf will trigger F0000. This is especially dangerous because a bad pg_hba.conf can block all incoming connections.

-- View currently loaded pg_hba.conf rules (PostgreSQL 10+)
SELECT line_number, type, database, user_name, address, auth_method
FROM pg_hba_file_rules
ORDER BY line_number;

-- Identify lines with errors
SELECT line_number, type, database, user_name, address, error
FROM pg_hba_file_rules
WHERE error IS NOT NULL;

-- After fixing the file, reload configuration
SELECT pg_reload_conf();

A valid pg_hba.conf entry follows this structure:

-- Correct format reference (as SQL comments):
-- TYPE   DATABASE   USER      ADDRESS           METHOD
-- host   all        all       127.0.0.1/32      scram-sha-256
-- host   mydb       myuser    192.168.1.0/24    md5
-- hostssl all       all       0.0.0.0/0         scram-sha-256

3. File Permission or Ownership Issues

If the PostgreSQL process cannot read the configuration files due to incorrect ownership or restrictive permissions, F0000 is raised. This often happens after OS migrations, container rebuilds, or manual file transfers.

-- Locate configuration files from within PostgreSQL
SHOW config_file;
SHOW hba_file;
SHOW data_directory;

-- After fixing OS-level permissions (postgres user must own the files),
-- reload the configuration
SELECT pg_reload_conf();

-- Confirm settings are loaded from the correct source
SELECT name, setting, source, sourcefile
FROM pg_settings
WHERE sourcefile IS NOT NULL
LIMIT 20;

Quick Fix Solutions

-- Step 1: Identify the problem parameter or file
SELECT name, setting, source, sourcefile, sourceline
FROM pg_settings
WHERE source = 'configuration file';

-- Step 2: Use ALTER SYSTEM for safe, SQL-validated changes
ALTER SYSTEM SET max_connections = 100;
ALTER SYSTEM SET shared_buffers = '128MB';

-- Step 3: Roll back a bad ALTER SYSTEM change
ALTER SYSTEM RESET shared_buffers;
ALTER SYSTEM RESET ALL;

-- Step 4: Reload and confirm
SELECT pg_reload_conf();

Prevention Tips

Use ALTER SYSTEM instead of manually editing postgresql.conf.
ALTER SYSTEM writes to postgresql.auto.conf and validates values immediately, preventing bad settings from ever reaching the file.

-- Audit all non-default settings for review
SELECT name, setting, boot_val, source, sourcefile, sourceline
FROM pg_settings
WHERE setting != boot_val
  AND source NOT IN ('default', 'override')
ORDER BY name;

Always back up config files before editing and validate with a staging server first.
Incorporate a pg_reload_conf() check into your deployment pipeline and monitor pg_hba_file_rules for any error IS NOT NULL rows after every change.

Related Error Codes

Code	Name	Relation
`57P03`	`cannot_connect_now`	Server fails to start due to config error
`28000`	`invalid_authorization_specification`	Bad `pg_hba.conf` auth method
`08006`	`connection_failure`	Client rejected due to `pg_hba.conf` error
`58P01`	`undefined_file`	Config file not found at expected path

Oracle ORA-14406 Error: Causes and Solutions Complete Guide

umzzil nng — Thu, 24 Sep 2026 14:01:31 +0000

ORA-14406: Updated Partition Key Is Beyond Highest Legal Partition Key

ORA-14406 occurs in Oracle when an UPDATE statement attempts to change a partition key column to a value that exceeds the highest boundary defined across all partitions in a RANGE-partitioned table. Essentially, Oracle cannot find a valid destination partition for the updated row. This error is most common in RANGE-partitioned tables that lack a MAXVALUE catch-all partition.

Top 3 Causes and Fixes

Cause 1: No MAXVALUE Partition Defined

When a RANGE-partitioned table is created with fixed upper bounds and no MAXVALUE partition, any UPDATE that pushes the partition key beyond the last defined boundary triggers ORA-14406.

Check your partition structure:

SELECT partition_name, high_value, partition_position
FROM   user_tab_partitions
WHERE  table_name = 'SALES'
ORDER BY partition_position;

Fix — Add a new partition or split the last one:

-- Option 1: Add a new partition
ALTER TABLE sales
ADD PARTITION p2025
VALUES LESS THAN (TO_DATE('2026-01-01', 'YYYY-MM-DD'));

-- Option 2: Split the last partition to create a MAXVALUE safety net
ALTER TABLE sales
SPLIT PARTITION p_last
AT (TO_DATE('2026-01-01', 'YYYY-MM-DD'))
INTO (
  PARTITION p2025,
  PARTITION p_last
);

Long-term fix — Use INTERVAL partitioning (Oracle 11g+):

CREATE TABLE sales (
  sale_id   NUMBER,
  sale_date DATE,
  amount    NUMBER
)
PARTITION BY RANGE (sale_date)
INTERVAL (NUMTOYMINTERVAL(1, 'MONTH'))
(
  PARTITION p_init VALUES LESS THAN (TO_DATE('2024-01-01','YYYY-MM-DD'))
);

With INTERVAL partitioning, Oracle automatically creates new partitions as data arrives, eliminating ORA-14406 entirely.

Cause 2: ROW MOVEMENT Not Enabled

When you UPDATE a partition key and the new value belongs to a different partition, Oracle needs ROW MOVEMENT enabled on the table. Without it, Oracle blocks the operation — sometimes surfacing as ORA-14402 or ORA-14406.

Check and enable ROW MOVEMENT:

-- Check current status
SELECT table_name, row_movement
FROM   user_tables
WHERE  table_name = 'SALES';

-- Enable ROW MOVEMENT
ALTER TABLE sales ENABLE ROW MOVEMENT;

-- Retry your UPDATE
UPDATE sales
SET    sale_date = TO_DATE('2025-08-01', 'YYYY-MM-DD')
WHERE  sale_id = 5001;

COMMIT;

Cause 3: Bad Data from ETL or Application Logic

Date conversion bugs, unit mismatches (e.g., milliseconds vs. seconds), or unvalidated input can push abnormally large values into partition key columns during batch loads or UPDATE statements.

Detect out-of-range values before updating:

-- Identify problematic rows
SELECT sale_id, sale_date
FROM   sales_staging
WHERE  sale_date >= TO_DATE('2026-01-01', 'YYYY-MM-DD')
   OR  sale_date IS NULL;

-- Quarantine bad rows
INSERT INTO sales_error_log (sale_id, sale_date, error_msg, log_date)
SELECT sale_id, sale_date, 'ORA-14406: key out of range', SYSDATE
FROM   sales_staging
WHERE  sale_date >= TO_DATE('2026-01-01', 'YYYY-MM-DD');

-- Apply UPDATE only for valid rows
UPDATE sales s
SET    s.sale_date = (
         SELECT st.sale_date FROM sales_staging st
         WHERE  st.sale_id = s.sale_id
           AND  st.sale_date < TO_DATE('2026-01-01', 'YYYY-MM-DD')
       )
WHERE  EXISTS (
         SELECT 1 FROM sales_staging st
         WHERE  st.sale_id = s.sale_id
           AND  st.sale_date < TO_DATE('2026-01-01', 'YYYY-MM-DD')
       );

COMMIT;

Prevention Tips

1. Always include a MAXVALUE partition or use INTERVAL partitioning.
Never leave a RANGE-partitioned table without a fallback. Add VALUES LESS THAN (MAXVALUE) as the final partition, or migrate to INTERVAL partitioning so Oracle handles new ranges automatically. Set up a monitoring job to alert you when partition boundaries are approaching expiration.

2. Validate partition key values in every ETL and batch pipeline.
Before any bulk UPDATE or INSERT, run a pre-check query to confirm all partition key values fall within defined boundaries. Route out-of-range records to an error table and trigger an alert — catching the problem in staging is far cheaper than diagnosing it in production.

Related Errors

ORA-14400 — Partition key does not map to any partition (on INSERT)
ORA-14402 — Updating partition key would cause a partition change (ROW MOVEMENT disabled)
ORA-14408 — Partition contains rows that prevent the operation

DEV Community: umzzil nng

PostgreSQL HV010 Error: Causes and Solutions Complete Guide

PostgreSQL Error HV010: fdw_function_sequence_error

Top 3 Causes

1. FDW Callback Function Order Violation

2. Extension Version Mismatch After Upgrade

3. Abnormal Transaction or Cursor Usage

Quick Fix Checklist

Prevention Tips

Related Error Codes

Oracle ORA-16000 Error: Causes and Solutions Complete Guide

ORA-16000: Database Open for Read-Only Access

Top 3 Causes

1. Accidentally Connected to a Data Guard Standby Database

2. Database Explicitly Opened in READ ONLY Mode

3. PDB (Pluggable Database) Opened as READ ONLY

Quick Fix Solutions

Prevention Tips

Related Oracle Errors

PostgreSQL HV002 Error: Causes and Solutions Complete Guide

PostgreSQL Error HV002: fdw dynamic parameter value needed

Top 3 Causes

1. Missing Parameter Binding in Prepared Statements

2. Incomplete FDW Server or User Mapping Configuration

3. FDW Extension Version Mismatch or Bug

Quick Fix Solutions

Prevention Tips

Related Errors

Oracle ORA-14501 Error: Causes and Solutions Complete Guide

ORA-14501: Object Is Not Partitioned — Causes, Fixes & Prevention

Top 3 Causes

1. Running Partition DDL Against a Regular Table

2. Applying Partition Commands to a Global Non-Partitioned Index

3. Automated Scripts Without Partition Validation

Quick Fix Solutions

Prevention Tips

Related Errors

PostgreSQL HV005 Error: Causes and Solutions Complete Guide

PostgreSQL Error HV005: fdw_column_name_not_found

Top 3 Causes

1. Column Name Mismatch Between Foreign Table and Remote Table

2. Remote Schema Changed Without Updating Foreign Table

3. Incorrect OPTIONS (column_name ...) Value

Quick Fix Solutions

Prevention Tips

Related Errors

Oracle ORA-14427 Error: Causes and Solutions Complete Guide

ORA-14427: table does not have ROW MOVEMENT enabled

Top 3 Causes

1. Updating a Partition Key Column on a Partitioned Table

2. Using Flashback Table Without ROW MOVEMENT Enabled

3. Partition Maintenance and Data Migration Scripts

Quick Fix

Prevention Tips

Related Errors

PostgreSQL HV000 Error: Causes and Solutions Complete Guide

PostgreSQL Error HV000: FDW Error — Causes, Fixes, and Prevention

Top 3 Causes

1. External Server Connection Failure

2. Invalid User Mapping or Credentials

3. Foreign Table Schema Mismatch

Quick Fix Checklist

Prevention Tips

Oracle ORA-14424 Error: Causes and Solutions Complete Guide

ORA-14424: Cannot Shrink a Segment That Does Not Have Row Movement Enabled

Top 3 Causes

1. ROW MOVEMENT Not Enabled on the Target Table

2. Partitioned Table SHRINK Without Table-Level ROW MOVEMENT

3. LOB Segment SHRINK Without Enabling ROW MOVEMENT

Quick Fix Solutions

Prevention Tips

Related Errors

PostgreSQL F0001 Error: Causes and Solutions Complete Guide

PostgreSQL F0001: lock file exists — What It Means and How to Fix It

Top 3 Causes

1. Leftover PID File After Abnormal Shutdown

2. Duplicate Instance Launch Attempts

3. NFS or Shared Storage Mount Issues

Quick Fix Solutions

Prevention Tips

3. Incorrect `OPTIONS (column_name ...)` Value

1. Syntax Errors or Invalid Values in `postgresql.conf`

2. Malformed Rules in `pg_hba.conf`