Re: BUG #15858: could not stat file - over 4GB
| От | Juan José Santamaría Flecha |
|---|---|
| Тема | Re: BUG #15858: could not stat file - over 4GB |
| Дата | |
| Msg-id | CAC+AXB2164H1JjSOPwf=PK5AhRVHSApzC5NAU-443HSu7RotSA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #15858: could not stat file - over 4GB (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>) |
| Ответы |
Re: BUG #15858: could not stat file - over 4GB
|
| Список | pgsql-hackers |
On Thu, Sep 17, 2020 at 8:47 PM Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> wrote:
On Thu, Sep 17, 2020 at 6:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:One thing I noticed, which is a pre-existing problem but maybe now
is a good time to consider it, is that we're mapping lstat() to be
exactly stat() on Windows. That made sense years ago when (we
believed that) Windows didn't have symlinks, but surely it no longer
makes sense.I will have to take a better look at it, but from a quick look it, all lstat() calls seem to test just if the file exists, and that can be done with a cheap call to GetFileAttributes(). Would a limited (but fast) lstat(), where only st_mode could be informed, be acceptable?
After thinking more about this, that approach would be problematic for DELETE_PENDING files. The proposed patch logic is meant to maintain current behaviour, which is not broken for WIN32 symlinks AFAICT.
Regards,
Juan José Santamaría Flecha
В списке pgsql-hackers по дате отправления: