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 по дате отправления:

Предыдущее
От: Amit Khandekar
Дата:
Сообщение: Re: Redundant tuple copy in tqueueReceiveSlot()
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting