1d4a0ab19a
Renaming a file using rename(2) is not guaranteed to be durable in face of crashes. Use the previously added durable_rename()/durable_link_or_rename() in various places where we previously just renamed files. Most of the changed call sites are arguably not critical, but it seems better to err on the side of too much durability. The most prominent known case where the previously missing fsyncs could cause data loss is crashes at the end of a checkpoint. After the actual checkpoint has been performed, old WAL files are recycled. When they're filled, their contents are fdatasynced, but we did not fsync the containing directory. An OS/hardware crash in an unfortunate moment could then end up leaving that file with its old name, but new content; WAL replay would thus not replay it. Reported-By: Tomas Vondra Author: Michael Paquier, Tomas Vondra, Andres Freund Discussion: 56583BDD.9060302@2ndquadrant.com Backpatch: All supported branches |
||
|---|---|---|
| .. | ||
| Makefile | ||
| pg_stat_statements--1.0--1.1.sql | ||
| pg_stat_statements--1.1--1.2.sql | ||
| pg_stat_statements--1.2--1.3.sql | ||
| pg_stat_statements--1.3.sql | ||
| pg_stat_statements--unpackaged--1.0.sql | ||
| pg_stat_statements.c | ||
| pg_stat_statements.control | ||