A deep dive into PostgreSQL's `data_sync_retry` GUC, which exists as a direct consequence of 'fsyncgate' — a 2018 discovery that Linux silently discards dirty pages after writeback failures, marking them clean and reporting the error only once to whichever file descriptor calls fsync() first. This meant PostgreSQL could complete a checkpoint, recycle WAL, and permanently lose data with no indication anything went wrong. The fix (committed November 2018) changed the default behavior to PANIC on fsync() failure rather than retry, because crashing and replaying from WAL is the only safe recovery path — a retry can succeed against a page that no longer exists. Setting `data_sync_retry = on` restores the old unsafe retry behavior and is effectively a 'lose data silently' option on Linux. The post also covers the Linux kernel's partial fix via errseq_t in 4.13, PostgreSQL 12's file-descriptor improvements, and the still-incomplete Direct I/O work that would fully solve the problem.
