Re: BUG #15460: Error while creating index or constraint
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: paul.vanderlinden@mapcreator.eu, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2018-11-13T20:12:10Z
Lists: pgsql-bugs
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
Commits
-
Have BufFileSize() ereport() on FileSize() failure.
- 1a990b207b86 12.0 landed
- 95c45718126f 11.2 landed
-
Use 64 bit type for BufFileSize().
- fa2ceaca4358 11.2 landed
- aa5518304213 12.0 landed
-
Adjust trace_sort log messages.
- cb6f8a9a7243 12.0 landed
- 886319d71bd5 11.1 landed
-
Fix some sloppiness in the new BufFileSize() and BufFileAppend() functions.
- 445e31bdc749 11.0 cited