From owner-freebsd-fs@freebsd.org Fri Feb 15 12:09:11 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6588214D8E75 for ; Fri, 15 Feb 2019 12:09:11 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from mail.pingpong.net (mail.pingpong.net [109.228.164.3]) by mx1.freebsd.org (Postfix) with ESMTP id B882F8E2E2 for ; Fri, 15 Feb 2019 12:09:10 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from girgbook.pingpong.net (citron2.pingpong.net [195.178.173.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id 0089B275AD for ; Fri, 15 Feb 2019 13:09:08 +0100 (CET) From: Palle Girgensohn Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: fsync and latest PostgreSQL Message-Id: <7BEDD281-471D-47E7-A34D-CEF6C6296A01@FreeBSD.org> Date: Fri, 15 Feb 2019 13:09:08 +0100 To: "freebsd-fs@freebsd.org" X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: B882F8E2E2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; ASN(0.00)[asn:8473, ipnet:109.228.128.0/18, country:SE] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 12:09:11 -0000 Hi! I'm packaging postgresql ports for FreeBSD. I need your advice about a = change to the PostgreSQL backend that seems to be aimed at working = around a problem in Linux where the OS "lies" about fsync. There's a description here [1]: > data_sync_retry (boolean) >=20 > When set to false, which is the default, PostgreSQL will raise a = PANIC-level error on failure to flush modified data files to the = filesystem. This causes the database server to crash. >=20 > On some operating systems, the status of data in the kernel's page = cache is unknown after a write-back failure. In some cases it might have = been entirely forgotten, making it unsafe to retry; the second attempt = may be reported as successful, when in fact the data has been lost. In = these circumstances, the only way to avoid data loss is to recover from = the WAL after any failure is reported, preferably after investigating = the root cause of the failure and replacing any faulty hardware. >=20 > If set to true, PostgreSQL will instead report an error but continue = to run so that the data flushing operation can be retried in a later = checkpoint. Only set it to true after investigating the operating = system's treatment of buffered data in case of write-back failure. An email by the committer [2] indicates that it is safe to set = data_sync_retry =3D true for "all file systems on FreeBSD" but makes not = recommendations: > I personally believe it is safe to run with data_sync_retry =3D on on > any file system on FreeBSD, and ZFS on any operating system... but I > see no need to make recommendations about that in the documentation, > other than that you should investigate the behaviour of your operating > system if you really want to turn it on. I'm pondering about setting this knob to default true in the FreeBSD = ports. Any thoughts or comments about that? Cheers, Palle [1] = https://www.postgresql.org/docs/11/runtime-config-error-handling.html#GUC-= DATA-SYNC-RETRY = [2] = https://www.postgresql.org/message-id/CAEepm%3D16aauN3LMHrVZ-uoqU8-k7aoSdG= C3t7PghewVVsjUwtQ%40mail.gmail.com =