From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Getting rid of some more lseek() calls |
Date: | 2020-02-13 01:51:44 |
Message-ID: | CA+hUKG+npCwg=qmT_t_EeVRhknVRthDfe_+SB-zHjCrwLDEADw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Attachment | Content-Type | Size |
---|---|---|
0001-Introduce-pg_file_size-to-get-the-file-size-for-an-f.patch | application/octet-stream | 2.0 KB |
0002-Remove-lseek-calls-from-slru.c.patch | application/octet-stream | 3.6 KB |
0003-Remove-lseek-calls-from-walsender.c.patch | application/octet-stream | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-02-13 02:28:05 | Re: Exposure related to GUC value of ssl_passphrase_command |
Previous Message | Kyotaro Horiguchi | 2020-02-13 01:28:48 | Re: Identifying user-created objects |