Re: Getting rid of some more lseek() calls

On 2020-Feb-13, Thomas Munro wrote:

> On Thu, Feb 13, 2020 at 5:30 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > On 2020-Feb-12, Thomas Munro wrote:
> > > Hmm. Well, on Unix we have to choose between "tell me the size but
> > > also change the position that I either don't care about or have to
> > > undo", and "tell me the size but also tell me all this other stuff I
> > > don't care about". Since Windows apparently has GetFileSizeEx(), why
> > > not use that when that's exactly what you want? It apparently
> > > understands large files.
> >
> > I was already thinking that it might be better to make the new function
> > just "tell me the file size" without leaking the details of *how* we do
> > it, before reading about this Windows call. That reinforces it, IMO.
>
> Ok, how about this?

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.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services