PostgreSQL 對 fsync() 的修正

上次寫了「PostgreSQL 對 fsync() 的行為傷腦筋...」提到 fsync() 有些地方是與開發者預期不同的問題,但後面忘記跟進度...

剛剛看到 Percona 的人寫了「PostgreSQL fsync Failure Fixed – Minor Versions Released Feb 14, 2019」這篇才發現在 2/14 就出了對應的更新,從 release notes 也可以看到:

By default, panic instead of retrying after fsync() failure, to avoid possible data corruption (Craig Ringer, Thomas Munro)

Some popular operating systems discard kernel data buffers when unable to write them out, reporting this as fsync() failure. If we reissue the fsync() request it will succeed, but in fact the data has been lost, so continuing risks database corruption. By raising a panic condition instead, we can replay from WAL, which may contain the only remaining copy of the data in such a situation. While this is surely ugly and inefficient, there are few alternatives, and fortunately the case happens very rarely.

A new server parameter data_sync_retry has been added to control this; 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.

現在的 workaround 是遇到 fsync() 失敗時為了避免 data corruption,會直接 panic 讓整個 PostgreSQL 從 WAL replay 記錄,也代表 HA 機制 (如果有設計的話) 有機會因為這個原因被觸發...

不過也另外設計了 data_sync_retry,讓 PostgreSQL 的管理者可以硬把這個 panic 行為關掉,改讓 PostgreSQL 重新試著 fsync(),這應該是在之後 kernel 有修改時會用到...

Wal-Mart 與 Uber/Lyft 合作迎戰 Amazon

Amazon 透過各種技術整合的比較好 (像是先前發表無人機空運的技術 Amazon Prime Air),而 Wal-Mart 則是跟 Uber/Lyft 這樣的公司配合:「Wal-Mart Plans to Test Grocery Delivery Through Uber, Lyft」。

不過可以看到運費不算低,如果買的東西不多的話:

The move steps up competition with Amazon’s burgeoning grocery-delivery service and provides a potential new avenue of growth for Uber and Lyft. The idea is to let Wal-Mart customers pick out groceries online and then have employees fill the order and give it to one of the ride-hailing companies’ drivers. Shoppers will pay a $7-to-$10 delivery charge to Wal-Mart to have the groceries brought to their door.