Re: fdatasync(2) on macOS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fdatasync(2) on macOS
Date: 2021-01-18 04:08:49
Message-ID: 289866.1610942929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Sat, Jan 16, 2021 at 6:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2021-01-18 04:10:41 Re: Printing backtrace of postgres processes
Previous Message Fujii Masao 2021-01-18 04:08:07 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit