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.
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 |