Re: Getting rid of some more lseek() calls

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Getting rid of some more lseek() calls
Дата
Msg-id CA+hUKGLQn=h18Oa9jrerNPwN9rf0rPn7FFtuvdHDU3ROuXDaBA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Getting rid of some more lseek() calls  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Feb 14, 2020 at 4:47 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> So, you said lseek() is faster than fstat, and we would only use the
> latter because we want to avoid the file position jumping ahead, even
> though it's slower.  But if the next read/write is not going to care
> about the file position because pread/pwrite, then why not just do one
> lseek() and not worry about the file position jumping ahead?  Maybe the
> API could offer this as an option; caller can say "I do care about file
> position" (a boolean flag) and then we use fstat; or they can say "I
> don't care" and then we just do a single lseek(SEEK_END).  Of course, in
> Windows we ignore the flag since we can do it in the fast way.
>
> pg_file_size(int fd, bool careful)
>
> Let's have the function comment indicate that -1 is returned in case of
> failure.

Reviving an old thread... yeah, we should probably figure out if we
still want a central fd size function and how it should look, but in
the meantime, we might as well have slru.c using pread/pwrite as
already agreed, so I went ahead and pushed that part.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: psql - improve test coverage from 41% to 88%
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: display offset along with block number in vacuum errors