SQLSTATE 58030 PANIC Class 58: System Error

io_error could not fsync file “…” — 58030

PostgreSQL error “could not fsync file … — 58030” (SQLSTATE 58030): what it means, common causes, and how to fix it.

PG 9.6, 10, 11, 12, 13, 14, 15, 16, 17, 18 Official docs
Last reviewed Jun 2026 Grounded in source

Diagnostic Queries

Symptoms

PostgreSQL could not flush a file to durable storage with fsync. This threatens durability, so PostgreSQL raises SQLSTATE 58030 (io_error) and may PANIC.

  • An fsync system call failed.
  • Often a failing disk, full volume, or filesystem fault.
  • Durability of committed data is at risk.

What the server log shows

ERROR:  could not fsync file "base/16384/24576": Input/output error

Why PostgreSQL raises this — what the manual says

As Section 30.1 Reliability explains:

PostgreSQL relies on successfully flushing files to durable storage to guarantee crash safety; when fsync of a data or WAL file fails, the server treats it as a fatal condition rather than risk losing data that the operating system reported as written but never persisted.

Commits and checkpoints depend on fsync forcing buffered writes to disk. A failed fsync means the OS could not confirm durability, so PostgreSQL reports 58030 (and on checkpoint paths may PANIC) rather than risk silent data loss.

Common causes

  • Failing disk or storage controller.
  • A full filesystem rejecting the flush.
  • Network/remote storage dropping the fsync.

How to fix it

  1. Investigate storage/hardware health and free space immediately.
  2. Check OS logs for I/O errors on the underlying device.
  3. Restore from backup if the volume is damaged; never run with fsync = off in production.

Related & next steps

Reference: PostgreSQL 18 Section 30.1 “Reliability”.

Was this helpful?