Informix Error -79: No record locks available.
Cause and resolution
No record locks available.
An operating-system error code with the meaning shown was unexpectedly returned to the database server. This implementation of the IBM Corporation database server probably uses kernel locking, the use of the operating-system facilities to lock rows of tables. The capacity of the operating-system lock table has been exceeded. Contact your system administrator and inquire about configuring the operating system to support more locks. Also examine your database application to see if it can use fewer locks by updating fewer rows in each transaction or by locking whole tables instead of rows.
Oninit® Troubleshooting Guidance
This is an operating-system error number, not an Informix diagnosis.
The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.
This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.
Important platform note. Error codes in this range represent operating-system
errnovalues whose meanings vary between Unix platforms and versions. Confirm the nativeerrnodefinition on the server where the Informix error occurred before diagnosing the problem from the number alone.
Determine the Native Error Meaning
| Value | Symbol | |
|---|---|---|
| Catalogue text — No record locks available | 79 | ENOLCK on the catalogue's source platform |
| The same condition on Linux | 37 | ENOLCK — No record locks available |
| Errno 79 on Linux | 79 | ELIBACC — Cannot access a needed shared library, unrelated |
python3 -c 'import os; print(79, os.strerror(79)); print(37, os.strerror(37))'
What ENOLCK Actually Tells You
ENOLCK means the kernel's record-lock table itself is full — not that a specific record
is already locked by someone else (that's a normal, expected wait/block condition), but that
the OS has run out of room to track any more advisory locks system-wide. This is a capacity
exhaustion at the kernel level, distinct from ordinary lock contention: a lock request fails
outright rather than blocking, because there's no room left to even record that it's waiting.
What This Means in Informix
Per the official text, this implementation of the database server probably uses kernel locking — relying on the operating system's own facilities to lock rows of tables, rather than (or in addition to) an entirely in-process lock manager. When the OS-level lock table's capacity is exceeded, Informix's row-locking requests fail at the kernel boundary:
- A workload holding a very large number of row locks simultaneously, pushing the system-wide kernel lock table past its configured capacity — more likely under large transactions touching many rows, or a high-concurrency workload with many sessions each holding numerous locks.
- The kernel's lock-table size configured too small for the actual concurrent locking workload on the host, which may be shared with other processes and services also consuming kernel lock-table capacity.
- Other processes on the same host (not just Informix) consuming kernel lock-table capacity, leaving less room than expected for the database server's own locking.
Common Causes
- The operating system's kernel lock-table capacity being exceeded, per the official guidance — the direct, named cause.
- A transaction or workload updating an unusually large number of rows, each requiring a kernel-level lock under this implementation's locking model.
- Row-level locking where table-level locking would suffice, multiplying the number of individual kernel locks needed for a given operation.
- Kernel lock-table sizing not accounting for Informix's concurrent locking demand alongside whatever else on the host also uses kernel record locks.
Solutions / Resolution
- Contact your system administrator and inquire about configuring the operating system to support more locks, per the official guidance — this is the documented, direct resolution: raise the kernel's lock-table capacity.
- Examine your database application to see if it can use fewer locks, per the official guidance, by updating fewer rows in each transaction.
- Consider locking whole tables instead of rows, per the official guidance, as an alternative that trades granularity for a much smaller number of kernel locks held at once.
- Review concurrent workload and transaction sizing more broadly if raising the kernel limit and reducing per-transaction row counts both prove insufficient.
Examples
Checking current kernel lock usage (platform-dependent)
# Exact tooling and tunable name vary by platform/OS version; consult
# platform documentation for the kernel's record-lock table size and
# current usage before and after adjusting it.
Diagnostic Checks
- Confirm the symbol, since errno 79 means something unrelated on Linux:
python3 -c 'import os; print(79, os.strerror(79)); print(37, os.strerror(37))' - Identify the transaction(s) or workload holding an unusually large number of row locks at the time of the error.
- Check the kernel's configured record-lock table capacity against actual concurrent demand, on the affected host.
Related Errors / Related Topics
- -78 — "Deadlock situation detected/avoided." A neighboring kernel-locking condition — -78 is the kernel refusing a lock wait because it would deadlock, while -79 is the kernel's lock table running out of capacity entirely; distinct failure modes, same general area of the kernel.
- -77 — "Identifier removed." A different kind of OS-resource condition (System V IPC) in this same numeric cluster, unrelated in mechanism.
The kernel's record-lock table is out of capacity — per the official guidance, ask the system administrator to raise it, and reduce the number of rows locked per transaction (or lock whole tables) as an application-side mitigation.