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>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: BUG #15460: Error while creating index or constraint
Date: Mon, 29 Oct 2018 11:25:48 -0400
Message-ID: <26974.1540826748@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, pgsql-bugs@lists.postgresql.org, hlinnaka@iki.fi
Subject: Re: BUG #15460: Error while creating index or constraint
In-Reply-To: <26974.1540826748@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox