Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-10 Thread Thomas Munro
On Sun, Nov 10, 2024 at 8:12 PM Andrew Dunstan wrote: > Oh, ouch. I guess it's too late to add those for this release. Still, an > initdb failure is not as bad as a pg_rewind failure, IMNSHO. Yeah, I don't think it's all that bad. It seems both unlikely (certain kinds of junction points with no

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-09 Thread Andrew Dunstan
On Sat, Nov 9, 2024 at 11:20 AM Thomas Munro wrote: > On Sat, Nov 9, 2024 at 9:30 AM Andrew Dunstan wrote: > > My impression was that this was something we just didn't get around to. > I wouldn't have pushed these so close to release if this hadn't been code > already tested for a long time in r

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-08 Thread Thomas Munro
On Sat, Nov 9, 2024 at 9:30 AM Andrew Dunstan wrote: > My impression was that this was something we just didn't get around to. I > wouldn't have pushed these so close to release if this hadn't been code > already tested for a long time in release 16+. Maybe we missed something, but > I doubt it

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-08 Thread Andrew Dunstan
On Sat, Nov 9, 2024 at 2:33 AM Tom Lane wrote: > Robert Haas writes: > > On Thu, Nov 7, 2024 at 6:19 PM Andrew Dunstan > wrote: > >> Juan José Santamaría Flecha, reviewed by Emil Iggland; > >> based on prior work by Michael Paquier, Sergey Zubkovsky, and others > >> > >> Author: Alexandra Wang

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-08 Thread Andrew Dunstan
On Sat, Nov 9, 2024 at 6:11 AM Tom Lane wrote: > I wrote: > > I'm also confused about how to document them in the release notes. > > Alexandra should get some credit I guess for collecting and testing > > the patches, but she's not the original author(s). > > After thinking for awhile, I'm going

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-08 Thread Tom Lane
I wrote: > I'm also confused about how to document them in the release notes. > Alexandra should get some credit I guess for collecting and testing > the patches, but she's not the original author(s). After thinking for awhile, I'm going to fold all of these into one release-note entry:

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-08 Thread Tom Lane
Robert Haas writes: > On Thu, Nov 7, 2024 at 6:19 PM Andrew Dunstan wrote: >> Juan José Santamaría Flecha, reviewed by Emil Iggland; >> based on prior work by Michael Paquier, Sergey Zubkovsky, and others >> >> Author: Alexandra Wang > This authorship information is confusing. Yes. Worse, th

Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-08 Thread Robert Haas
On Thu, Nov 7, 2024 at 6:19 PM Andrew Dunstan wrote: > Juan José Santamaría Flecha, reviewed by Emil Iggland; > based on prior work by Michael Paquier, Sergey Zubkovsky, and others > > Author: Alexandra Wang This authorship information is confusing. -- Robert Haas EDB: http://www.enterprisedb.

pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2024-11-07 Thread Andrew Dunstan
Fix our Windows stat() emulation to handle file sizes > 4GB. Hack things so that our idea of "struct stat" is equivalent to Windows' struct __stat64, allowing it to have a wide enough st_size field. Instead of relying on native stat(), use GetFileInformationByHandle(). This avoids a number of iss

pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.

2020-10-09 Thread Tom Lane
Fix our Windows stat() emulation to handle file sizes > 4GB. Hack things so that our idea of "struct stat" is equivalent to Windows' struct __stat64, allowing it to have a wide enough st_size field. Instead of relying on native stat(), use GetFileInformationByHandle(). This avoids a number of iss