|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Peter Geoghegan <pg(at)bowt(dot)ie>|
|Cc:||pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: BufFileSize() doesn't work on a "shared" BufFiles|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 30/04/18 22:00, Peter Geoghegan wrote:
> On Mon, Apr 30, 2018 at 10:18 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> Perhaps that would be OK, if it was properly commented. But it's not
>> actually hard to make BufFileSize() work on shared files, too, so I think we
>> should do that.
> I agree that this could use a comment, but I don't see much point in
> adding the extra FileSeek(). The fact that fd.c is unwilling to track
> filesize for non-temp files (where "non-temp" means a
> PathNameOpenTemporaryFile()-returned/exported file) is due to
> vfdP->fileSize being involved in temp_file_limit enforcement. Maybe a
> FD_TEMP_FILE_LIMIT assertion within FileGetSize() would help?
Seems simpler to just make it work. It's not like the extra lseek() is
going to make any performance difference. Functions that work only under
certain conditions are annoying.
|Next Message||Tom Lane||2018-05-02 14:30:39||Re: Optimize Arm64 crc32c implementation in Postgresql|
|Previous Message||Tom Lane||2018-05-02 14:22:55||Re: Is a modern build system acceptable for older platforms|