On Wed, Nov 14, 2018 at 6:50 AM Peter Geoghegan <pg@bowt.ie> wrote:
> On Tue, Nov 13, 2018 at 1:50 AM Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > I think using pgoff_t would fix the problem on Windows, but on other
> > systems where it maps directly to off_t it might also be 32 bits, so
> > I'm not entirely sure what pgoff_t is for. Perhaps we should just use
> > int64 directly for this? Like in the attached draft patch. I don't
> > have a Windows system to test it on. A separate bug report that came
> > in today[1] has repro steps that could be used to validate it.
>
> I think that int64 is the way to go.
Thanks. So, a practical matter: The change of return type as
proposed is an ABI break for 32 bit off_t systems. BufFileSize() is
brand new and seems pretty unlikely to be used by extensions so soon.
Could we change that? A conservative alternative would be to define a
second function BufFileSize64() and use that for parallel CREATE INDEX
in REL_11_STABLE, leaving the off_t version as it is, but then fold
them back into a single version in master.
> Should I fix up the diagnostic message to address Tom's complaints
> about that in a separate patch?
+1
--
Thomas Munro
http://www.enterprisedb.com
