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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
