Re: FSM Corruption (was: Could not read block at end of the relation)
Ronan Dunklau <ronan.dunklau@aiven.io>
From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Noah Misch <noah@leadboat.com>, Michael Paquier <michael@paquier.xyz>, Patrick Stählin <patrick.staehlin@aiven.io>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Date: 2024-03-06T11:08:38Z
Lists: pgsql-bugs
Attachments
- 0002-Detect-invalid-FSM-when-finding-a-block.patch (text/x-patch)
Le mercredi 6 mars 2024, 11:59:43 CET Patrick Stählin a écrit : > 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. Good catch. Please find attached v2 of the patch. -- Ronan Dunklau
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