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+AXB01gg7PYY9EZoyWY=0hJBRQUoH2O1=dJzFzcp-GQcQ4SQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: BUG #15858: could not stat file - over 4GB
Список pgsql-hackers

On Thu, Sep 17, 2020 at 6:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> writes:
> Thanks for the reminder. Please find attached a rebased version.

(This hasn't shown up on -hackers yet, maybe caught in moderation?)

Thanks for looking into it. Finally, it went through. I will be removing bug-list from now on. 

I took a quick look through this.  I'm not qualified to review the
actual Windows code in win32stat.c, but as far as the way you're
plugging it into the system goes, it looks good and seems to comport
with the discussion so far.

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?

Another more trivial point is that it'd be good to run the new code
through pgindent before committing.

I do not have pgindent in the WIN32 machine, but I will try to for the next version.

Regards,

Juan José Santamaría Flecha

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgindent vs dtrace on macos
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: WIP: BRIN multi-range indexes