Database Management

DPA PostgreSQL Plan Poll Job Fails With “String or binary data would be truncated in table … CONPPT_xx, column PLAN_NODE”

On one or more PostgreSQL monitored instances, DPA intermittently stops plan polling and logs show a "PlanPollJob failed" error.

First published date

12/19/2025 10:34 PM

Last published date

12/19/2025 10:34 PM

Overview

Symptoms include:
  • The PlanPollJob for the affected monitor fails repeatedly.
  • DPA logs contain messages such as:
    “Monitor for database [name] failed in job [PlanPollJob] due to [String or binary data would be truncated … PLAN_NODE] … Will attempt to retry every [xx] seconds…”
  • The monitor may intermittently stop collecting plan data or appear unstable.

Product section

Database Performance Analyzer

Cause

This is a known defect in how DPA stores PostgreSQL execution plans in the repository.
  • DPA’s plan polling job (PlanPollJob) collects execution plans and stores each plan node as JSON in the PLAN_NODE column of the CONPPT_xx table (per monitored instance).
  • In some environments (especially Citus / distributed PostgreSQL and complex plans), the JSON plan nodes are larger than the defined size of the PLAN_NODE column, resulting in a data truncation / 2628 error when inserting into CONPPT_xx (for example CONPPT_9).
  • When this happens, the insert fails, which causes PlanPollJob to throw JobExecutionException, and plan polling for that instance fails and may stop or flap in and out of monitoring.
 

Resolution

A fix for this issue is planned for a future release of DPA. Until the permanent fix is available, use one of the following workarounds to stabilize monitoring.

Option 1 – Disable plan polling on the affected instance

Use this if plan collection can be temporarily paused but stable wait/metric monitoring is required.
  1. In the DPA web console, sign in as an administrator.
  2. Go to Options → Advanced options.
  3. Click the DB instance options tab.
  4. Check Support options (upper right).
  5. Select the affected PostgreSQL instance from the dropdown.
  6. Find PLANPOLL_ENABLED.
  7. Set the value to false and click Update.
Result:
  • Plan polling is disabled for that specific monitored instance, so no new plans are collected, but DPA continues to collect waits and other performance metrics.
  • This avoids the data truncation on PLAN_NODE, so PlanPollJob no longer fails and the monitor should remain stable.
This workaround is recommended in multiple similar truncation scenarios (PG and MySQL) and is the lowest‑risk option when monitoring stability is the top priority.
 

Option 2 – Exclude only the problematic database(s) from PostgreSQL plan polling

Use this when there are multiple databases under a single monitored PostgreSQL instance and only one or a few databases are generating oversized plans.
Step 1 – Identify the database(s) causing truncation
  1. Enable TRACE logging for plan polling:
    • https://<DPAserver>:8124/iwc/setLogger.iwc?logger=com.confio.idc.database.service.planpoll.AbstractPlanPollService&level=TRACE
    • https://<DPAserver>:8124/iwc/setLogger.iwc?logger=com.confio.idc.database.service.planpoll.PostgreSqlPlanPollService&level=TRACE
  2. Let the system run until the PlanPollJob error reproduces.
  3. Collect the new DPA logs and search idc.log for messages like:
    • “Query Plan for Postgres database …”
    • The same timeframe as the “String or binary data would be truncated … PLAN_NODE” errors.
  4. Note the database name(s) where plans are being captured immediately prior to the truncation error. These are usually the ones with very large plans (for example, certain Citus distributed databases).
Step 2 – Exclude those databases from plan polling
  1. In DPA: Options → Advanced options → DB instance options.
  2. Enable Support options.
  3. Select the same PostgreSQL instance.
  4. Set:
    • POSTGRESQL_PLAN_COLLECTION_DB_NAMES = dbname1;dbname2 (semicolon separated list, including only the large‑plan DBs you identified).
    • POSTGRESQL_PLAN_COLLECTION_DB_NAMES_FILTER = EXCLUDE.
Result:
  • DPA will continue plan polling for other databases under that monitored instance.
  • Plans will not be collected for the excluded databases, preventing the large plan JSON from overflowing the PLAN_NODE column and causing truncation.
This pattern has been successfully used by PostgreSQL users with very large plans, where completely disabling plan polling was not acceptable.

 

Verification

After applying any workaround:
  1. Confirm that the PlanPollJob is no longer failing for the affected instance(s):
    • Monitor logs for the absence of
      String or binary data would be truncated in table '...CONPPT_xx', column 'PLAN_NODE'
      and PlanPollJob failed entries.
  2. Confirm DPA monitor status:
    • The monitor should remain green and should not be cycling between up and down states.
  3. Confirm expected plan behavior:
    • Option 1 (PLANPOLL_DISABLED): No new plans are collected for that instance.
    • Option 2 (DB exclusion): Plans are collected for other databases; excluded databases no longer show new plan captures.
If truncation errors persist after these steps, attach the latest idc.log and errors.log, plus an updated repository schema snapshot for the CONPPT_xx table(s), and engage DPA engineering.