Informix Error -175

Reasons / Common Causes

-175 is different from most internal-error codes in this range: the official text says the database server will automatically retry the operation. This is an internal lock/buffer sequencing condition — attempting to acquire a row lock while already holding a buffer (an internal memory structure used during page access) — that the engine recognizes and generally resolves on its own, rather than a failure requiring external intervention.

1. An internal lock-ordering condition between buffer holding and lock acquisition — a specific internal sequencing situation the engine detects and handles via automatic retry.
2. Transient internal contention between buffer and lock resources under normal operation — the framing of automatic retry suggests this is an expected, usually brief condition rather than a persistent problem.
3. High-concurrency workloads with heavy buffer/lock contention potentially surfacing this more often, though the automatic retry generally resolves it without visible application impact.
4. If this appears in client-visible output despite the "will retry" framing, it may indicate the automatic retry mechanism itself struggled unusually, or that the message was logged for diagnostic purposes even though the retry ultimately succeeded.

Solutions / Resolution

1. In most cases, no direct application action is needed. Given the official framing that the engine automatically retries, this is largely a self-resolving internal condition rather than something to fix from the application side.
2. If this appears frequently in logs or monitoring, treat it as a possible indicator of high buffer/lock contention worth investigating from a performance perspective — reviewing buffer pool and lock configuration sizing — rather than as a discrete bug.
3. If it ever surfaces as an actual client-facing failure (not just a log entry), gather the circumstances and escalate — given the automatic-retry framing, a persistent failure despite retry would be unusual and worth reporting.
4. Review buffer pool and lock configuration sizing as a preventive tuning measure if frequency correlates with periods of heavy concurrent load.

Examples

Monitoring context, not a discrete failure

-- Frequent appearances of this message in online.log during peak
-- concurrent load, with no corresponding client-facing failures,
-- is consistent with the engine's automatic retry working as designed

When it's worth investigating further

-- If application code or monitoring shows this correlating with
-- actual failed operations (not just log entries), that's the
-- signal to gather circumstances and escalate, since automatic
-- retry apparently didn't resolve it

Diagnostic Checks

1. Check how frequently this appears in logs or monitoring relative to overall workload — occasional appearances during high concurrency are consistent with expected, self-resolving behavior.
2. Review buffer pool and lock configuration if frequency correlates with periods of high concurrent load.
3. Confirm whether this ever surfaces as an actual client-facing failure, versus only appearing as an internal/log event that the automatic retry resolved.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -134 — "ISAM error: no more locks." The closest sibling in the lock-resource-management family, though -134 is a hard capacity exhaustion rather than an internal sequencing condition the engine resolves automatically.

Unlike most conditions in this range, -175 generally doesn't require action — confirm it's not surfacing as an actual client-facing failure, and otherwise treat frequent occurrences as a performance-tuning signal rather than a bug to fix.