On Wed, Jul 24, 2019 at 01:30:42PM -0400, Tom Lane wrote:
> Hm. AFAICS the immediate issuer of the error must have been
> _mdnblocks(); there are other matches to that error string but
> they are in places where we can tell which file the seek must
> have been applied to, and it wasn't a FSM file.
Yep, that matches my guesses. _mdnblocks() is the only match among
the three places with this error string.
> lseek() per se presumably would never return ENOENT. A more likely
> theory is that the file wasn't actually open but only had a leftover
> VFD entry, and when FileSize() -> FileAccess() tried to open it,
> the open failed with ENOENT --- but _mdnblocks() would still call it
> a seek failure.
>
> So I'd opine that this is a pretty high-level failure --- what are
> we doing trying to replay WAL against a table that's been dropped?
> Or if it wasn't dropped, why was the FSM removed?
Interesting theory. In this particular workload, all DDLs are run
when the product runs firstboot and the schema does not change
afterwards, so the stuff does not drop any tables. Actually I have
been able to extract more information from the log bundles I have as
this stuff does a lookup of all the files of the data folder at the
moment a log bundle is taken. For this relation the main fork exists
on the primary and there is no FSM and VM. On the standby, the main
fork also exists but there is a FSM, which I guess has been rebuilt at
the follow-up recovery. So could it be possible that a FSM has been
removed on the primary, with its removal done on the standby because
of that without the proper VFD entry cleaned up?
--
Michael