We are seeing repeated panic's from this code, quite often (always?) on follower nodes, which makes the message about "could not access stable table on leader" surprising.
I'm guessing that the code here should use ENOENT, which can be returned by __wt_open_cursor. That would make the panic case specific to when we couldn't open the cursor and we're on a follower.
ret = __wt_open_cursor(session, stable_uri, &clayered->iface, cfg, &clayered->stable_cursor);
if (ret == ENOENT && !leader) {
/*
* This is fine, we may not have seen a checkpoint with this table yet. The open will be
* deferred.
*/
ret = 0;
} else if (ret == WT_NOTFOUND)
WT_ERR_PANIC(session, WT_PANIC, "Layered table could not access stable table on leader");
else
WT_ERR(ret);
- is related to
-
WT-15835 Two small fixes for layered cursors
-
- Closed
-
-
WT-15717 Investigate high cache size usage with precise checkpoints enabled in test/format
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
WT-15848 Incorrect log printed when plh_get_page_ids is not implemented
-
- Closed
-
- related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
WT-15816
Opening a stable cursor can return both ENOENT and WT_NOTFOUND
-
- Open
-