58000

At a glance

58000 is the system-error condition. In the fixed backend path, pg_promote creates the promotion signal file and then calls kill(PostmasterPid, SIGUSR1); a failed signal reports ERROR with the operating-system text substituted for %m.

Meaning

The representative backend primary is exactly failed to send signal to postmaster: %m. The code unlinks the promotion signal file before raising ERROR, so the failed system call is part of a postmaster-notification path, not a user value or SQL syntax failure. The shared common/exec.c source uses a log_error macro that has two compile-time branches. In a non-FRONTEND build it expands to ereport(LOG, (errcodefn, errmsg_internal(...))); in a FRONTEND build it ignores the errcode() argument and prints the formatted text to stderr. Thus the frontend utility message is not proof of a client-protocol 58000 diagnostic or a client transaction abort. The separate pg_log_error macro in common/logging.h maps to PG_LOG_ERROR, but pclose_check() does not call that macro.

Messages

• Backend pg_promote signal path: primary failed to send signal to postmaster: %m, severity ERROR. The expanded text depends on the OS errno at the failed kill() call.
• Shared pclose_check() source: the call-site template is %s() failed: %m; with pclose() it expands to pclose() failed: <OS text>. Non-FRONTEND builds log it through ereport(LOG) with the supplied ERRCODE_SYSTEM_ERROR; FRONTEND builds ignore that code and print to stderr, so this is not a client-protocol 58000 path.

Diagnosis

Preserve the full primary after %m expansion, the operation (promotion signal, pclose, or another system helper), process identity, and server or utility log context. For backend pg_promote, inspect the postmaster PID, signal permissions/process liveness, and the OS error. Do not replace the OS-specific cause with a generic disk, permission, or process diagnosis without the actual errno. The SQLSTATE alone does not establish transaction outcome.

Response

Correct the operating-system condition identified by the expanded message, then verify postmaster/server health before retrying the operation. A backend ERROR normally aborts the current explicit transaction, so send ROLLBACK or ROLLBACK TO SAVEPOINT before continuing; in autocommit, retry only after the cause is fixed. A frontend log from pclose_check has its utility’s own control flow and does not call for a SQL transaction rollback. If the connection was lost, reconnect after readiness and verify business effects.

Versions

The locked catalogue records this condition from 9.2.0; that boundary does not prove the exact implementation-introduction version. Fixed source coverage is PostgreSQL 18.6.

Related

57P01, 57P02, XX000

Sources

src/backend/access/transam/xlogfuncs.c#L702-708

src/common/exec.c#L52-70

src/common/exec.c#L391-412

src/include/common/logging.h#L106-110

The structured evidence record records the backend and frontend/common message boundaries.