Re: There's some sort of race condition with the new FSM stuff

Tom Lane wrote:
> I wrote:
>> Two different buildfarm machines are currently showing the same failure:
>> ERROR: could not fsync segment 0 of relation 1663/16384/29270/1: No such file or directory
>> ERROR: checkpoint request failed
>
> Some tests show that when the serial regression tests are run in a
> freshly initdb'd installation, HEAD assigns OID 29270 to "bmscantest"
> in the bitmapops test. So that's been dropped some time before the
> failure occurs; which means that this isn't a narrow-window race
> condition; which raises the question of why we're not seeing it on more
> machines. I notice now that kudu and dragonfly are actually the same
> machine ... could this be an OS-specific problem? Kris, has there been
> any system-software change on that machine recently?

Must be because of this little missing line here:

--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -1012,6 +1012,7 @@ ForwardFsyncRequest(RelFileNode rnode, ForkNumber
forknum, BlockNumber segno)
}
request = &BgWriterShmem->requests[BgWriterShmem->num_requests++];
request->rnode = rnode;
+ request->forknum = forknum;
request->segno = segno;
LWLockRelease(BgWriterCommLock);
return true;

Most fsync requests are for main fork, not FSM, so I guess what usually
happens because of that bug is that the we skip the fsync on the FSM,
which is why we haven't noticed before.

I still wonder, though, why we're seeing the error consistently on kudu,
and not on any other animal. Perhaps the forknum field that's left
uninitialized gets a different value there than on other platforms.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com