Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Date
Msg-id 21981.1266939533@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after  (Greg Stark <stark@mit.edu>)
Responses Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> I don't like using configure tests for this because I fear someone
> could compile Postgres on a system with one set of behaviour and then
> switch to a different kernel version with a different set of
> behaviour. In the worst case it could be filesystem dependent whether
> you can open directories or whether they accept fsyncs.

Yeah, and there's also the problem of cross-compilation.  I don't want
a configure test either if we can avoid it.

> The plan I was thinking of was to pass a flag indicating if it's a
> directory to fsync_fname() and open it RD_ONLY if it's a directory and
> RDRW if it's a file. Then ignore any error returns (or at least EBADF
> and EINVAL) iff the flag indicating it was a directory was true.

Works for me, but let's first try just ignoring EBADF, which is the only
value we saw in the recent buildfarm failures.  If we got past the fd<0
test then EBADF could only indicate a rdonly failure, whereas it's less
clear what EINVAL might cover.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: "Kevin Grittner"
Date:
Subject: Re: function side effects