From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: paul.vanderlinden@mapcreator.eu,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
        Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: BUG #15460: Error while creating index or constraint
In-reply-to: 
 <CAH2-Wzk=pj9SN+=HZCYwAc3WHe+_SErqA3xoLxj2y_GwSQ+Dag@mail.gmail.com>
References: <15460-b6db80de822fa0ad@postgresql.org>
 <CAH2-Wzk=pj9SN+=HZCYwAc3WHe+_SErqA3xoLxj2y_GwSQ+Dag@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Mon, 29 Oct 2018 11:41:19 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26973.1540826748.1@sss.pgh.pa.us>
Date: Mon, 29 Oct 2018 11:25:48 -0400
Message-ID: <26974.1540826748@sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Oct 26, 2018 at 10:32 AM PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> pg_restore: [archiver (db)] could not execute query: ERROR:  could not
>> determine size of temporary file "0"
>> Command was: CREATE INDEX nx_tablename ON tablename USING btree (col1);

> I'm not sure what the exact problem might be, because I can't see why
> the BufFileSize() thing would fail, even on Windows.

So there are a couple of things to complain about here with respect
to the error message, regardless of the underlying bug:

* "0" is not a file name.  Reporting it is just about useless, and
identifying it as a "file" is a lie.  Why aren't we reporting the
actual name of the underlying file?  (I realize that we might not
have easy access to that right here.  But now that this has been
shown to be reachable in the field, it seems worth doing some extra
work to make the error message useful.)

* We aren't reporting the errno (no %m in the message).  By luck,
the errcode_for_file_access() call is enough to let us infer that
it was ENOENT in this case, but in other cases that might not be
enough.

> I think that
> using lseek() + SEEK_END to get the size of a file may only work on
> POSIX, and yet I can see the same pattern in much older code (e.g.,
> _mdnblocks()).

Yeah, that works fine on Windows AFAIK.  I also note that ENOENT
isn't an error code that lseek() can deliver, anyway, since it works
on an already-open FD.  The failure here must be coming from opening
the file.

I'm a little inclined to suspect that the true cause here is workers
not correctly computing the name of this temp file, which is what
led me to complain about the error message.  Although a weak spot in
this theory is that it's not clear why they'd not fail later anyway,
unless maybe this particular file never got touched by workers before.

> I have a strong suspicion that going back to passing the size through
> shared memory (i.e. partially reverting 445e31bdc74) would make the
> problem go away, but I won't do that until I actually understand
> what's going on.

Sounds like papering over the bug ...

			regards, tom lane