For a new page saved outside of any running transaction, the missing spaces (the space of the page and its missing parents) are inserted before the page transaction starts: a short transaction reads the space table, then each missing space is inserted, parent first, in its own short transaction, all committed and closed before the page transaction takes its database connection. So a save never needs two connections of the pool at the same time on this path. A rename does the same for the target page before its transaction.
The spaces are inserted hidden. The page transaction makes the space and its parents visible for a visible page, with an UPDATE that only changes hidden rows and stops at the first visible space. If the page save fails afterwards, only hidden empty spaces remain; the next page saved in such a space reuses the row.
A constraint violation in an insert transaction (or a deadlock reported by MySQL/MariaDB) is accepted only if a new transaction then finds the space row, meaning that another thread or cluster member inserted it first. Any other error, including another constraint such as NOT NULL, makes the page save fail with the original error.
The in-memory space lock is kept around each insert, with a re-check of the row, so the threads of a single instance wait for the first insert instead of hitting the constraint.
If the space is still missing inside the page transaction (a page not known as new, a save that is part of a larger transaction, or a space deleted in the meantime), the missing spaces are inserted the same way; only this rare case uses a second connection while the page transaction holds one.
Cost: one extra short connection use and primary key lookup on the space table for each new page save.
Not addressed here: a page saved in a space while the last page of that space is being deleted can still end up without a space row (the same race on the deletion side, also present before this change); it will be reported separately.
PS: This post was co-written with Claude Code.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.