Re: Windows now has fdatasync()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windows now has fdatasync()
Date: 2022-07-18 03:43:59
Message-ID: 545705.1658115839@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:
> With my garbage collector hat on, I see that all systems we target
> have fdatasync(), except:

> 1. Windows, but this patch supplies src/port/fdatasync.c.
> 2. DragonflyBSD before 6.1. We have 6.0 in the build farm.
> 3. Ancient macOS. Current releases have it, though we have to cope
> with a missing declaration.

Hmmm ... according to [1], while current macOS has an undocumented
fdatasync function, it doesn't seem to do anything as useful as,
say, sync data to disk. I'm not sure what direction you're headed
in here, but it probably shouldn't include assuming that fdatasync
is actually useful on macOS. But maybe that's not your point?

> My plan now is to commit this patch so that problem #1 is solved, prod
> conchuela's owner to upgrade to solve #2, and wait until Tom shuts
> down prairiedog to solve #3.

You could force my hand by pushing something that requires this ;-).
I'm not feeling particularly wedded to prairiedog per se. As with
my once-and-future HPPA machine, I'd prefer to wait until NetBSD 10
is a thing before spinning up an official buildfarm animal, but
I suppose that that's not far away.

regards, tom lane

[1] https://www.postgresql.org/message-id/1673109.1610733352%40sss.pgh.pa.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-07-18 04:12:42 Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Previous Message shiy.fnst@fujitsu.com 2022-07-18 03:28:03 RE: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns