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

It happens with both unique and non-unique index.
When I disable virusscanner I also get the error, but settin g the max_parallel_workers to 0 does let me create the index

-----Original Message-----
From: Peter Geoghegan <pg@bowt.ie> 
Sent: maandag 29 oktober 2018 13:27
To: Paul van der Linden <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

On Mon, Oct 29, 2018 at 11:41 AM Peter Geoghegan <pg@bowt.ie> wrote:
> 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.

BufFileOpenShared()/SharedFileSetOpen() is allowed to fail in the event of no file (an ENOENT) within PathNameOpenTemporaryFile(). OTOH,
BufFileSize() can throw an error due to the same condition following 445e31bdc74, which is what we see here. If it's okay in the first function, why shouldn't it be okay in the second function, which is called shortly afterwards? That's where Paul's ERRCODE_UNDEFINED_FILE actually comes from. ISTM that only one of those assumptions can be correct.

I thought that parallel CREATE INDEX didn't need to rely on this ENOENT-is-okay business, and that that was just there for parallel hash join, which is why I didn't complain when 445e31bdc74 went in. It now seems like logtape.c could correctly rely on ENOENT-is-okay, though. I think that temporary file "0" is almost always the leader-as-worker fileset, which may be relevant.

Paul: Does varying whether an index is unique or not change the outcome of any of your failing test cases?

Does anyone see a way in which the logtape.c + shared buffile stuff could come to rely on assuming that an ENOENT case relates to an empty worker BufFile? I suppose it's also possible that there is a bug that partially reverting 445e31bdc74 would only mask, though that seems less likely.

--
Peter Geoghegan