On Fri, Nov 29, 2019 at 3:13 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Wed, Nov 27, 2019 at 7:53 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > 2019-11-26 23:41:50.009-05 | could not fsync file "pg_tblspc/16401/PG_12_201909212/16460/973123799.10": No such file or directory
>
> I managed to reproduce this (see below). I think I know what the
> problem is: mdsyncfiletag() uses _mdfd_getseg() to open the segment to
> be fsync'd, but that function opens all segments up to the one you
> requested, so if a lower-numbered segment has already been unlinked,
> it can fail. Usually that's unlikely because it's hard to get the
> request queue to fill up and therefore hard to split up the cancel
> requests for all the segments for a relation, but your workload and
> the repro below do it. In fact, the path it shows in the error
> message is not even the problem file, that's the one it really wanted,
> but first it was trying to open lower-numbered ones. I can see a
> couple of solutions to the problem (unlink in reverse order, send all
> the forget messages first before unlinking anything, or go back to
> using a single atomic "forget everything for this rel" message instead
> of per-segment messages), but I'll have to think more about that
> tomorrow.
Here is a patch that fixes the problem by sending all the
SYNC_FORGET_REQUEST messages up front.