On Fri, Oct 26, 2018 at 10:32 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
> On large tables I get an error on:
>
> CREATE INDEX nx_tablename ON tablename USING btree (col1); col1 being an
> integer
> and
> ALTER TABLE ONLY tablename ADD CONSTRAINT pk_tablename PRIMARY KEY (col1,
> col2); col1 and col2 both integer
>
> First noticed that with pg_restore (from a pg_dump from PG10)
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 14005; 1259 546886907 INDEX
> nx_tablename postgres
> 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 initially suspected that this was caused by commit 445e31bdc74. This
commit made the parallel CREATE INDEX leader call BufFileSize(),
rather than having each worker call it themselves. It is where the
error message from Paul actually originated from. The commit also
changed BufFileSize() so that it would lseek(), rather than just
passing filesize metadata through shared memory.
I'm not sure what the exact problem might be, because I can't see why
the BufFileSize() thing would fail, even on Windows. 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()). I don't have a Windows machine, and the spec seems
rather hard to read here.
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.
--
Peter Geoghegan