Re: Getting rid of some more lseek() calls - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Getting rid of some more lseek() calls
Date
Msg-id CA+hUKGLQn=h18Oa9jrerNPwN9rf0rPn7FFtuvdHDU3ROuXDaBA@mail.gmail.com
Whole thread Raw
In response to Re: Getting rid of some more lseek() calls  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: psql - improve test coverage from 41% to 88%
Next
From: Justin Pryzby
Date:
Subject: Re: display offset along with block number in vacuum errors