Re: fdatasync(2) on macOS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fdatasync(2) on macOS
Date
Msg-id 289866.1610942929@sss.pgh.pa.us
Whole thread Raw
In response to Re: fdatasync(2) on macOS  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: fdatasync(2) on macOS  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Sat, Jan 16, 2021 at 6:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I have a vague recollection that we discussed changing the default
>> wal_sync_method for Darwin years ago, but I don't recall why we
>> didn't pull the trigger.  These results certainly suggest that
>> we oughta.

> No strong preference here, at least without more information. It's
> unsettling that two of our wal_sync_methods are based on half-released
> phantom operating system features, but there doesn't seem to be much
> we can do about that other than try to understand what they do.  I see
> that the idea of defaulting to fsync_writethrough was discussed a
> decade ago and rejected[1].
> [1] https://www.postgresql.org/message-id/flat/AANLkTik261QWc9kGv6acZz2h9ZrQy9rKQC8ow5U1tAaM%40mail.gmail.com

Ah, thanks for doing the archaeology on that.  Re-reading that old
thread, it seems like the two big arguments against making it
safe-by-default were

(1) other platforms weren't safe-by-default either.  Perhaps the
state of the art is better now, though?

(2) we don't want to force exceedingly-expensive defaults on people
who may be uninterested in reliable storage.  That seemed like a
shaky argument then and it still does now.  Still, I see the point
that suddenly degrading performance by orders of magnitude would
be a PR disaster.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Next
From: Craig Ringer
Date:
Subject: Re: Printing backtrace of postgres processes