Re: BufFileSize() doesn't work on a "shared" BufFiles
От | Peter Geoghegan |
---|---|
Тема | Re: BufFileSize() doesn't work on a "shared" BufFiles |
Дата | |
Msg-id | CAH2-WznEDYe_NZXxmnOfsoV54oFkTdMy7YLE2NPBLuttO96vTQ@mail.gmail.com обсуждение исходный текст |
Ответ на | BufFileSize() doesn't work on a "shared" BufFiles (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: BufFileSize() doesn't work on a "shared" BufFiles
|
Список | pgsql-hackers |
On Mon, Apr 30, 2018 at 10:18 AM, Heikki Linnakangas <hlinnaka@iki.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
В списке pgsql-hackers по дате отправления: