Horton

Re: BUG #15460: Error while creating index or constraint

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: paul.vanderlinden@mapcreator.eu, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2018-11-28T19:31:48Z
Lists: pgsql-bugs

Attachments

On Mon, Oct 29, 2018 at 8:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So there are a couple of things to complain about here with respect
> to the error message, regardless of the underlying bug:

Attached patch fixes the problems with BufFileSize(), while also
making similar adjustments to a closely related buffile.c "ereport() +
errcode_for_file_access()" in passing -- the ereport() from
BufFileOpenShared(). Note that both BufFileOpenShared() and
BufFileSize() are used in a closely coordinated way already -- we
literally call one immediately after the other from logtape.c. I don't
like the current inconsistency in error handling.

My approach implies a minor API break in BufFileSize(), but I think
that that's okay -- see the draft commit message for an explanation.
Beyond what I say there, I think that any third party client code
ought to be following the example of tuplestore_rescan(), and seeking
to the end of the BufFile directly. BufFileSize() should just be a
shared BufFile thing, in case it needs to be changed in the future.

-- 
Peter Geoghegan

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.