Hi - is this likely to be applied to an upcoming release? / How does a novice apply a patch..?
Thanks -----Original Message----- From: Juan José Santamaría Flecha <juanjo.santama...@gmail.com> Sent: 04 September 2019 22:48 To: Tom Lane <t...@sss.pgh.pa.us> Cc: Michael Paquier <mich...@paquier.xyz>; williamedwinal...@live.com; pgsql-b...@lists.postgresql.org; Magnus Hagander <mag...@hagander.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.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 <t...@sss.pgh.pa.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 configure.in (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. > Fixed. > 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. Regards, Juan José Santamaría Flecha
