Re: Windows now has fdatasync() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Windows now has fdatasync()
Date
Msg-id 545705.1658115839@sss.pgh.pa.us
Whole thread Raw
In response to Re: Windows now has fdatasync()  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Windows now has fdatasync()
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.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



pgsql-hackers by date:

Previous
From: "shiy.fnst@fujitsu.com"
Date:
Subject: RE: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Next
From: Amit Kapila
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns