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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Дата
Msg-id 21981.1266939533@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after  (Greg Stark <stark@mit.edu>)
Ответы Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: A thought on Index Organized Tables
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: function side effects