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

  1. Have BufFileSize() ereport() on FileSize() failure.

  2. Use 64 bit type for BufFileSize().

  3. Adjust trace_sort log messages.

  4. Fix some sloppiness in the new BufFileSize() and BufFileAppend() functions.