mirror of https://github.com/postgres/postgres
There is no reason to do durable_unlink before durable_rename. Rename can handle existing file. But with this sequence, the cluster may endup in unrecoverable state should server crash in-between this two ops, as there is going to be no "_keys" at all. The current sequence may also cause an issue the backup: <durable_unlink>, <pg_basebackup gets a file list>, <durable_rename>. And no "_keys" file in the backup as the result.pull/238/head
parent
fb543801dc
commit
a711d8befa
Loading…
Reference in new issue