]> granicus.if.org Git - postgresql/commit
Introduce durable_rename() and durable_link_or_rename().
authorAndres Freund <andres@anarazel.de>
Thu, 10 Mar 2016 02:53:53 +0000 (18:53 -0800)
committerAndres Freund <andres@anarazel.de>
Thu, 10 Mar 2016 02:53:53 +0000 (18:53 -0800)
commit606e0f9841b820d826f837bf741a3e5e9cc62fa1
treed26d471c0dd68be5d5704091d7ef490767b32f1a
parente19e4cf0be2892d3c894d6e37b905024f5977ab2
Introduce durable_rename() and durable_link_or_rename().

Renaming a file using rename(2) is not guaranteed to be durable in face
of crashes; especially on filesystems like xfs and ext4 when mounted
with data=writeback. To be certain that a rename() atomically replaces
the previous file contents in the face of crashes and different
filesystems, one has to fsync the old filename, rename the file, fsync
the new filename, fsync the containing directory.  This sequence is not
generally adhered to currently; which exposes us to data loss risks. To
avoid having to repeat this arduous sequence, introduce
durable_rename(), which wraps all that.

Also add durable_link_or_rename(). Several places use link() (with a
fallback to rename()) to rename a file, trying to avoid replacing the
target file out of paranoia. Some of those rename sequences need to be
durable as well. There seems little reason extend several copies of the
same logic, so centralize the link() callers.

This commit does not yet make use of the new functions; they're used in
a followup commit.

Author: Michael Paquier, Andres Freund
Discussion: 56583BDD.9060302@2ndquadrant.com
Backpatch: All supported branches
src/backend/replication/logical/origin.c
src/backend/replication/slot.c
src/backend/storage/file/fd.c
src/backend/storage/file/reinit.c
src/include/storage/fd.h