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
