Highlight: Change in behavior with fsync()
When available in an operating system and enabled in the configuration file (which it is by default), PostgreSQL uses the kernel function fsync() to help ensure that data is written to a disk. In some operating systems that provide fsync(), when the kernel is unable to write out the data, it returns a failure and flushes the data that was supposed to be written from its data buffers.
This flushing operation has an unfortunate side-effect for PostgreSQL: if PostgreSQL tries again to write the data to disk by again calling fsync(), fsync() will report back that it succeeded, but the data that PostgreSQL believed to be saved to the disk would not actually be written. This presents a possible data corruption scenario.
This update modifies how PostgreSQL handles a fsync() failure: PostgreSQL will no longer retry calling fsync() but instead will panic. In this case, PostgreSQL can then replay the data from the write-ahead log (WAL) to help ensure the data is written. While this may appear to be a suboptimal solution, there are presently few alternatives and, based on reports, the problem case occurs extremely rarely.
A new server parameter data_sync_retry has been added to manage this behavior. If you are certain that your kernel does not discard dirty data buffers in such scenarios, you can set data_sync_retry to on to restore the old behavior.
발렌타인데이에 , PostgreSQL 새버전이 나왔네요
가장 눈에 띄는점은, 위의 사항인데요
fsync() 실패시에, fsync 재시도 대신에 data corruption 방지를 위해서 panic 을 유발하도록 했습니다.
이전 버전 처럼 동일하게 작동하길 원한다면, 즉 fsync 실패시에 fsync 재시도 하도록
새로운 패러미터인 data_sync_retry=on 으로 세팅하면된다는 내용입니다.
