RE: BUG #15858: could not stat file - over 4GB

From: william allen <williamedwinallen(at)live(dot)com>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: BUG #15858: could not stat file - over 4GB
Date: 2019-10-28 14:28:59
Message-ID: DB6P189MB03760378FA59801300ACAF63C3660@DB6P189MB0376.EURP189.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

Hi - is this likely to be applied to an upcoming release? / How does a novice apply a patch..?


-----Original Message-----
From: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Sent: 04 September 2019 22:48
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>; williamedwinallen(at)live(dot)com; pgsql-bugs(at)lists(dot)postgresql(dot)org; Magnus Hagander <magnus(at)hagander(dot)net>; PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15858: could not stat file - over 4GB

Thanks for looking into this.

On Fri, Aug 23, 2019 at 11:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Directly editing the configure script is Not Done ... or at least,
> such changes wouldn't survive the next correctly-done configure
> update. You have to edit (or one of the sub-files in
> config/) and then regenerate configure using autoconf.
> It seems likely that we *don't* need or want this for Cygwin; that
> should be providing a reasonable stat() emulation already.
> So probably you just want to add "AC_LIBOBJ(win32_stat)" to the stanza
> beginning
> I'd also recommend that stat() fill all the fields in struct stat,
> even if you don't have anything better to put there than zeroes.
> Otherwise you're just opening things up for random misbehavior.


> I'm not in a position to comment on the details of the conversion from
> GetFileAttributesEx results to struct stat, but in general this seems
> like a reasonable way to proceed.

Actually, due to the behaviour of GetFileAttributesEx with symbolic links I think that using GetFileInformationByHandle instead can give a more resilient solution. Also, by using a handle we get a good test for ERROR_DELETE_PENDING. This is the approach for the attached patch.


Juan José Santamaría Flecha

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Josef Machytka 2019-10-28 15:18:59 Re: memory problems and crash of db when deleting data from table with thousands of partitions
Previous Message Pavel Stehule 2019-10-28 07:35:35 Re: BUG #16083: Different Result

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2019-10-28 14:40:44 Re: pg_upgrade fails with non-standard ACL
Previous Message Tom Lane 2019-10-28 14:07:39 Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'