Re: FSM Corruption (was: Could not read block at end of the relation)
Patrick Stählin <patrick.staehlin@aiven.io>
From: Patrick Stählin <patrick.staehlin@aiven.io>
To: Ronan Dunklau <ronan.dunklau@aiven.io>, Noah Misch <noah@leadboat.com>,
Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Date: 2024-03-06T10:59:43Z
Lists: pgsql-bugs
On 3/6/24 10:31, Ronan Dunklau wrote: > Le mardi 5 mars 2024, 00:05:03 CET Noah Misch a écrit : >> I would guess this one is more risky from a performance perspective, since >> we'd be adding to a hotter path under RelationGetBufferForTuple(). Still, >> it's likely fine. > > I ended up implementing this in the attached patch. The idea is that we detect > if the FSM returns a page past the end of the relation, and ignore it. > In that case we will fallback through the extension mechanism. @@ -582,7 +583,17 @@ RelationGetBufferForTuple(Relation relation, Size len, * We have no cached target page, so ask the FSM for an initial * target. */ + nblocks = RelationGetNumberOfBlocks(relation); targetBlock = GetPageWithFreeSpace(relation, targetFreeSpace); I'd move the fetching of nblocks to after getting the targetBlock. This avoids extending the relation in the unlikely event of a FSM/relation extension in-between those two calls. Patrick
Commits
-
freespace: Don't return blocks past the end of the main fork.
- 08059fc049ff 14.12 landed
- 7c490a18b75b 15.7 landed
- 4e62ba21a921 16.3 landed
- 935829743151 17.0 landed
-
Fix WAL-logging of FSM and VM truncation.
- 917dc7d2393c 10.0 cited
-
Extend relations multiple blocks at a time to improve scalability.
- 719c84c1be51 9.6.0 cited