Re: BufFileSize() doesn't work on a "shared" BufFiles

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
Date: 2018-05-02 14:24:45
Message-ID: d5ded7e9-954f-01c4-296e-b1dbc5b91a7c@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Pushed, thanks.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
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