Re: Volatile write caches on macOS and Windows, redux

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Volatile write caches on macOS and Windows, redux
Date: 2024-06-05 06:32:31
Message-ID: 01b98671-1f23-447a-95e2-36a2b5a7bf05@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.06.24 17:28, Nathan Bossart wrote:
>> I agree, two states should be enough. It could basically just be
>>
>> pg_fsync(int fd)
>> {
>> #if macos
>> fcntl(fd, F_FULLFSYNC);
>> #else
>> fsync(fd);
>> #endif
>> }
> IIUC with this approach, anyone who is using a file system that fails
> fcntl(F_FULLSYNC) with ENOSUPP would have to turn fsync off. That might be
> the right thing to do since having a third option that sends the data to
> the disk cache but doesn't provide any real guarantees if you lose power
> may not be worth much. However, if such a file system_did_ provide such
> guarantees with just fsync(), then it would be unfortunate to force people
> to turn fsync off. But this could very well all be hypothetical, for all I
> know... In any case, I agree that we should probably use F_FULLFSYNC by
> default on macOS.

Yeah, my example code above says "#if macos", not "#ifdef F_FULLSYNC".
The latter might be a problem along the lines you describe if other
systems use that symbol in a slightly different manner.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-06-05 06:36:28 Re: Build with LTO / -flto on macOS
Previous Message Peter Smith 2024-06-05 06:32:16 Re: Synchronizing slots from primary to standby