Andres Freund bfa282a02b Avoid unlikely data-loss scenarios due to rename() without fsync. ... 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		2016-03-09 18:53:54 -08:00
..
Makefile
pg_stat_statements--1.0--1.1.sql	Backpatch: Fix typo in update scripts for some contrib modules.	2014-08-25 18:30:46 +02:00
pg_stat_statements--1.1.sql
pg_stat_statements--unpackaged--1.0.sql	Fix typos in some error messages thrown by extension scripts when fed to psql.	2014-08-25 18:30:46 +02:00
pg_stat_statements.c	Avoid unlikely data-loss scenarios due to rename() without fsync.	2016-03-09 18:53:54 -08:00
pg_stat_statements.control