|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Greg Stark <stark(at)mit(dot)edu>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after|
|Views:||Raw Message | Whole Thread | Download mbox|
Greg Stark <stark(at)mit(dot)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
|Next Message||Kevin Grittner||2010-02-23 15:40:34||Re: function side effects|
|Previous Message||Simon Riggs||2010-02-23 15:28:06||Re: A thought on Index Organized Tables|
|Next Message||Tom Lane||2010-02-23 16:13:06||Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after|
|Previous Message||Greg Stark||2010-02-23 09:12:02||Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after|