From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
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-04-30 19:00:08 |
Message-ID: | CAH2-WznEDYe_NZXxmnOfsoV54oFkTdMy7YLE2NPBLuttO96vTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> Another little bug I noticed is that BufFileAppend() incorrectly resets the
> 'offsets' of the source files. You won't notice if you call BufFileAppend()
> immediately after BufFileOpenShared(), but if you had called BufFileSeek()
> or BufFileRead() on the shared BufFile handle before calling
> BufFileAppend(), it would get confused.
Seems worth fixing.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-04-30 19:02:11 | Re: [HACKERS] Add hint for function named "is" |
Previous Message | Tom Lane | 2018-04-30 18:59:43 | Re: Issues while building PG in MS Windows, using MSYS2 and MinGW-w64 |