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

From Tom Lane
Subject Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
Date
Msg-id 3647360.1731081780@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
List pgsql-committers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Nov 7, 2024 at 6:19 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>> Juan José Santamaría Flecha, reviewed by Emil Iggland;
>> based on prior work by Michael Paquier, Sergey Zubkovsky, and others
>>
>> Author: Alexandra Wang <alexandra.wang.oss@gmail.com>

> This authorship information is confusing.

Yes.  Worse, there is no link to what prompted this sudden burst
of back-patches of years-old commits.  After digging around I guess
it was this thread:

https://www.postgresql.org/message-id/flat/CA%2BpA0kLc5VxOaO4WfLjmh7W0V%2BquVvVtT5CaRVRAZMuh0zft4Q%40mail.gmail.com

I'm nervous about pushing these in mere hours before a release freeze,
primarily because there's no way to be sure whether any necessary
follow-up fixes got missed.  If we were unwilling to back-patch at
the time, is reversing that decision such a good idea?

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).

            regards, tom lane



pgsql-committers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Fix our Windows stat() emulation to handle file sizes > 4GB.
Next
From: Peter Geoghegan
Date:
Subject: pgsql: Avoid nbtree parallel scan currPos confusion.